Method and apparatus for testing wireless communication channels

ABSTRACT

Techniques to test a wireless communication link. A traffic channel is tested via a test data service option (TDSO) that may be negotiated and connected similar to other services. Test parameters values may be proposed, accepted or rejected, and negotiated. Test data for a channel is generated based on a defined data pattern or a pseudo-random number generator. Sufficient test data may be generated based on the generator for a test interval, stored to a buffer, and thereafter retrieved from a particular section of the buffer to form data block(s) for each “active” frame. The traffic channel may be tested using discontinuous transmission. A two-state Markov chain determines whether or not to transmit test data for each frame. The average frame activity and average burst length are defined by selecting the probabilities for transitioning between the ON/OFF states of the Markov chain, which may be driven by a second generator.

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of provisional U.S.application Serial No. 60/175,463, entitled “IS-2000 TEST DATA SERVICEOPTION,” filed Jan. 10, 2000, which is incorporated herein by referencein its entirety for all purposes.

BACKGROUND OF THE INVENTION

[0002] 1. Field of the Invention

[0003] The present invention relates to data communication. Moreparticularly, the present invention relates to novel and improved methodand apparatus for testing wireless communication channels.

[0004] 2. Description of the Related Art

[0005] Wireless communication systems such as code division multipleaccess (CDMA) systems, time division multiple access (TDMA) systems, andothers are widely used to provide various types of communication such asvoice, data, and so on. For these wireless systems, it is highlydesirable to utilize the available resources (i.e., bandwidth andtransmit power) as efficiently as possible. This typically entailstransmitting as much data to as many users within as short a time periodas supported by the conditions of the communication links.

[0006] To achieve the above goal, the communication links between atransmitting source (e.g., a base station) and the receiving devices(e.g., “connected” remote terminals) within the system may becharacterized. Based on the characterized link conditions for the remoteterminals, the system may be better able to select a particular set ofremote terminals to serve, allocate a portion of the available resources(e.g., transmit power) to each selected remote terminal, and transmit toeach remote terminal at a data rate supported by the allocated transmitpower and characterized link conditions.

[0007] Conventionally, a communication link is characterized bytransmitting (e.g., from a base station) a known data pattern (e.g.,generated by a defined pseudo-random number generator), receiving thetransmitted data pattern, comparing the received data pattern with alocally generated data pattern to determine transmission errors, andreporting the results back to the transmitting source. This “loop-back”testing is typically performed continuously for a number of frames overthe desired test interval. The test results are reflective of theperformance of the communication link over that test interval.

[0008] Many newer generation wireless communication systems are capableof flexible operation. For example, data may be transmitted in burstsand over one or more traffic channels (or physical channels), the datarate may be allowed to vary from frame to frame, the processing of thedata may also vary (e.g., from frame to frame and/or from channel tochannel), and so on. The conventional loop-back test technique typicallycharacterizes the communication link (e.g., one traffic channel) basedon a defined set of test parameters, and may not provide an accurateassessment of the performance of the communication link when the systemoperates in this flexible manner.

[0009] As can be seen, techniques that can be used to characterize acommunication link under various flexible operating conditions supportedby a wireless communication system are highly desirable.

SUMMARY OF THE INVENTION

[0010] The present invention provides various techniques to test awireless communication link. In one aspect, the testing of a trafficchannel is performed via a test data service option (TDSO), which is aservice that may be negotiated and connected using the available serviceconfiguration and negotiation procedures defined by a particular (CDMA)system and used for other services (e.g., a voice call, a data call).Values for test parameters may be proposed by an entity (e.g., a remoteterminal), accepted or rejected by the other entity (e.g., a basestation), and alternative values for rejected values may also beprovided by the other entity. The negotiation may be performed for eachtraffic channel to be tested.

[0011] In another aspect, to test a traffic channel, test data isgenerated based on a defined data pattern or a pseudo-random numbergenerator. Sufficient test data may be generated for a test interval(e.g., 10.24 sec) based on values from the pseudo-random numbergenerator, and the generated test data may be stored to a (circular)buffer. Test data may thereafter be retrieved, as necessary, from aparticular section of the buffer to form one or more data blocks foreach “active” frame in the test interval in which test data is to betransmitted. The particular section of the buffer from which to retrievethe test data may be identified by a particular “offset” from a currentbuffer pointer location, and this offset may be determined based on anumber from the pseudo-random number generator. Each data block may beappropriately identified by a header to enable concurrent testing ofmultiple traffic channels and for testing frames having multiple datablocks per frame. In an embodiment, one pseudo-random number generatorand one buffer are provided (at the transmission source and also at thereceiving device) for each traffic channel, either on the forward orreverse link, to be tested.

[0012] A traffic channel may be tested using discontinuous transmission.In this case, a two-state first-order Markov chain may be used todetermine whether or not to transmit test data for each frame in thetest interval. By selecting the proper probabilities of transitioningbetween an ON state (signifying transmission of test data) and an OFFstate (signifying no transmission of test data) of the Markov chain, theaverage frame activity and average burst length (two parameters thatdefine a discontinuous transmission) may be defined. The Markov chainmay be driven by a second pseudo-random number generator, which may bedifferent than the one used to generate the test data.

[0013] At a receiving device, the transmitted test data is received,processed in a complementary manner, and provided to a controller. Thecontroller further directs local generation of the test data based on apseudo-random number generator, which is synchronized to the generatorat the transmitting source. The locally generated test data is stored ina buffer and thereafter retrieved from the buffer (as necessary) andcompared against the received test data. Various performance andstatistical data may be collected at the remote terminal based on theresults of the comparison between the received and generated test data.

[0014] The testing of the reverse link may be achieved in similar manneras that for the forward link. Multiple traffic channels on the forwardand reverse links may be tested concurrently. Independent testing of thetraffic channels is possible by testing each traffic channel based on arespective set of test parameter values. Thus, the forward link trafficchannels and reverse link traffic channels may be tested based onsymmetric or asymmetric test parameter values. The traffic channelsunder test may have different frame lengths.

[0015] The invention further provides other methods and system elementsthat implement various aspects, embodiments, and features of theinvention, as described in further detail below.

BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The features, nature, and advantages of the present inventionwill become more apparent from the detailed description set forth belowwhen taken in conjunction with the drawings in which like referencecharacters identify correspondingly throughout and wherein:

[0017]FIG. 1 is a diagram of a spread spectrum communication system thatsupports a number of users;

[0018]FIGS. 2A and 2B are block diagrams of an embodiment of a basestation and a remote terminal, respectively, capable of implementingvarious aspects and embodiments of the invention;

[0019]FIG. 3 is a flow diagram of a process for generating test datausing a pseudo-random number generator, in accordance with a specificembodiment of the invention;

[0020]FIG. 4 is a block diagram of the buffers and pseudo-random numbergenerators used for generating pseudo-random test data for two trafficchannels;

[0021]FIG. 5 is a diagram that illustrates the reshuffling of apseudo-random number to generate a number for the test data;

[0022]FIG. 6 is a diagram that illustrates test data transmission for adiscontinuous transmission (DTX) scheme based on a deterministic frameactivity;

[0023]FIG. 7 is a diagram of a two-state first-order Markov chain thatmay be used to model the ON/OFF states for a DTX scheme based onpseudo-random frame activity;

[0024]FIG. 8 is a flow diagram of an embodiment of a process fortransitioning between the ON and OFF states of the Markov chain for atraffic channel; and

[0025]FIG. 9 is a diagram of an embodiment of a test data block.

DETAILED DESCRIPTION OF THE SPECIFIC EMBODIMENTS

[0026]FIG. 1 is a diagram of a spread spectrum communication system 100that supports a number of users. System 100 provides communication for anumber of cells, with each cell being serviced by a corresponding basestation 104. Various remote terminals 106 are dispersed throughout thesystem. Each remote terminal 106 may communicate with one or more basestations 104 on the forward and reverse links at any particular moment,depending on whether or not the remote terminal is active and whether ornot it is in soft handoff. As shown in FIG. 1, base station 104 acommunicates with remote terminals 106 a, 106 b, 106 c, and 106 d andbase station 104 b communicates with remote terminals 106 d, 106 e, and106 f.

[0027] A system controller 102 couples to base stations 104 and mayfurther couple to a public switched telephone network (PSTN). Systemcontroller 102 provides coordination and control for the base stationscoupled to it. System controller 102 further controls the routing oftelephone calls among remote terminals 106, and between remote terminals106 and the users coupled to PSTN (e.g., conventional telephones), viabase stations 104. For a CDMA system, system controller 102 is alsoreferred to as a base station controller (BSC).

[0028] System 100 may be designed to support one or more CDMA standardssuch as the “TIA/EIA-95-B Mobile Station-Base Station CompatibilityStandard for Dual-Mode Wideband Spread Spectrum Cellular System” (theIS-95 standard), the “TIA/EIA-98-D Recommended Minimum Standard forDual-Mode Wideband Spread Spectrum Cellular Mobile Station” (the IS-98standard), the “TIA/EIA/IS-2000.2-A Physical Layer Standard for cdma2000Spread Spectrum Systems”, the “TIA/EIA/IS-2000.5-A Upper Layer (Layer 3)Signaling Standard for cdma2000Spread Spectrum Systems”, the standardoffered by a consortium named “3rd Generation Partnership Project”(3GPP) and embodied in a set of documents including Document Nos. 3G TS25.211, 3G TS 25.212, 3G TS 25.213, and 3G TS 25.214 (the W-CDMAstandard), the standard offered by a consortium named “3rd GenerationPartnership Project 2” (3GPP2) and embodied in a set of documentsincluding Document Nos. C.S0002-A, C.S0005-A, C.S0010-A, C.S0011-A andC.S0026 (the cdma2000 standard), or some other standards. Thesestandards are incorporated herein by reference.

[0029] Some newer generation CDMA systems are capable of concurrentlysupporting voice and data transmissions, and may further be able totransmit to a particular remote terminal via a number of forward trafficchannels. For example, in the cdma2000 system, a fundamental channel maybe assigned for voice and certain types of data, and one or moresupplemental channels may be assigned for high-speed packet data.

[0030]FIG. 2A is a block diagram of an embodiment of base station 104,which is capable of implementing various aspects and embodiments of theinvention. For simplicity, FIG. 2A shows the processing at the basestation for a communication with one remote terminal. On the forwardlink, voice and packet data (collectively referred to herein as“traffic” data) from a transmit (TX) data source 210 and test data froma forward link (FL) test data buffer 212 are provided to a multiplexer(MUX) 214. Multiplexer 214 selects and provides the traffic data to a TXdata processor 216 when operating in a normal mode, and provides thetest data when operating in a test mode. TX data processor 216 receivesand processes (e.g., formats, encodes, and interleaves) the receiveddata, which is then further processed (e.g., covered, spread, andscrambled) by a modulator (MOD) 218. The modulated data is then providedto an RF TX unit 222 and conditioned (e.g., converted to one or moreanalog signals, amplified, filtered, and quadrature modulated) togenerate a forward link signal. The forward link signal is routedthrough a duplexer (D) 224 and transmitted via an antenna 226 to aremote terminal.

[0031] Although not shown in FIG. 2A for simplicity, base station 104 iscapable of processing and transmitting data on one or more forwardtraffic channels to a particular remote terminal. For a cdma2000 system,the forward traffic channels include the fundamental channel (FCH),dedicated control channel (DCCH), supplemental channel (SCH), andsupplemental code channel (SCCH). The processing (e.g., encoding,interleaving, covering, and so on) for each forward traffic channel maybe different from that of other forward traffic channels.

[0032]FIG. 2B is a block diagram of an embodiment of remote terminal106. The forward link signal is received by an antenna 252, routedthrough a duplexer 254, and provided to an RF receiver unit 256. RFreceiver unit 256 conditions (e.g., filters, amplifies, downconverts,and digitizes) the received signal and provides samples. A demodulator(DEMOD) 258 receives and processes (e.g., despreads, decovers, and pilotdemodulates) the samples to provide recovered symbols. Demodulator 258may implement a rake receiver capable of processing multiple instancesof the received signal and generating combined recovered symbols. Areceive (RX) data processor 260 decodes the recovered symbols, checksthe received frames, and provides decoded traffic data to a RX data sink264 and decoded test data to a controller 270. Demodulator 258 andreceive data processor 260 may be operated to process multipletransmissions received via multiple forward traffic channels.

[0033] On the reverse link, a multiplexer (MUX) 284 receives results ofthe forward traffic channel testing from controller 270, test data fortesting of the reverse link from a reverse link (RL) test data buffer278, and traffic data from a TX data source 282. Depending on theoperating mode of remote terminal 106, multiplexer 284 provides theproper combination of data and/or results to a TX data processor 286.The data and results are then processed (e.g., formatted, encoded, andinterleaved) by TX data processor 286, further processed (e.g., covered,spread) by a modulator (MOD) 288, and conditioned (e.g., converted toanalog signals, amplified, filtered, and quadrature modulated) by an RFTX unit 290 to generate a reverse link signal, which is then routedthrough duplexer 254 and transmitted via antenna 252 to one or more basestations 104.

[0034] Referring back to FIG. 2A, the reverse link signal is received byantenna 226, routed through duplexer 224, and provided to an RF receiverunit 228. The reverse link signal is conditioned (e.g., downconverted,filtered, and amplified) by RF receiver unit 228, and further processedby a demodulator 232 and an RX data processor 234 in a complementarymanner to recover the transmitted data and test results. The reverselink traffic data is provided to a RX data sink 238, and the forwardlink test results and reverse link test data are provided to acontroller 220 for evaluation.

[0035] As noted above, for efficient utilization of the available systemresources, the communication link between the base station and remoteterminal may be characterized. The link characterization information maythen be used to schedule data transmission, allocate transmit power,determine data rate, and so on, for the remote terminal.

[0036] The invention provides various techniques to test a wirelesscommunication link. In an aspect, to test a forward traffic channel,test data is generated at the base station by a test data generator 240and provided to FL test data buffer 212. The generated test data isthereafter retrieved from buffer 212 (as necessary), processed, andtransmitted from the base station to the remote terminal. At theterminal, the transmitted forward link test data is received, processedin a complementary manner, and provided to controller 270. Controller270 further directs a test data generator 280 to locally generate thetest data, which is stored in a FL test data buffer 268. The locallygenerated test data is thereafter retrieved from buffer 268 (asnecessary) and compared against the received test data. Variousperformance and statistical data may be collected at the remote terminalbased on the results of the comparison between the received andgenerated test data, as described in further detail below. The testingof the reverse link may be achieved in similar manner as that for theforward link.

[0037] For clarity, various aspects of the invention are described for aspecific implementation for a cdma2000 system.

[0038] Channel and Frame Structure

[0039] In some CDMA systems, data may be transmitted on one or moretraffic channels over the forward and reverse links. (A traffic channelmay be akin to a physical channel for some CDMA systems, e.g., a W-CDMAsystem.) For example, in a cdma2000 system, voice data is typicallytransmitted over a fundamental channel (FCH), traffic data is typicallytransmitted over a supplemental channel (SCH), and signaling may betransmitted over a dedicated control channel (DCCH). The FCH, DCCH, andSCH are different types of traffic channel. To receive a high-speed datatransmission on the SCH, a remote terminal is also typically assigned aFCH or DCCH. In the cdma2000 system, each assigned traffic channel isassociated with a particular radio configuration (RC) that defines thechannel's transmission formats, which may be characterized by variousphysical layer parameters such as the transmission rates, modulationcharacteristics, spreading rate, and so on.

[0040] For many CDMA systems, data is also transmitted in “frames”, witheach frame covering a particular time interval. For the cdma2000 system,data may be transmitted in frame lengths of 5 msec, 20 msec, 40 msec, or80 msec on the fundamental and supplemental channels. For each frame ofeach connected traffic channel, one or more data blocks may betransmitted, depending on the radio configuration of the trafficchannel.

[0041] In certain embodiments of the invention, the forward and reversetraffic channels are each subdivided into independent “test intervals”(which may also be referred to as “segments”). Each test interval has aduration of 10.24 seconds, which corresponds to 2048 frames for trafficchannels (FCH, DCCH) with 5 msec frame length, 512 frames for trafficchannels (FCH, DCCH, and SCH) with 20 msec frame length, 256 frames fortraffic channels (SCH) with 40 msec frame length, and 128 frames fortraffic channels (SCH) with 80 msec frame length. The first frame in thetest interval is referred to as a synchronization frame. In anembodiment, the synchronization frame for each of the forward andreverse traffic channels (FCH, DCCH, SCH0, and SCH1) is selected basedon (1) a 32-bit public long code mask (PLCM) assigned to the remoteterminal and (2) the system frame number (SFN) of the traffic channel'sframes, as described in further detail below. Thus, each traffic channelmay be associated with synchronization frames that are different(time-wise) from those of other traffic channels.

[0042] In an aspect, the CDMA system is designed to support a test dataservice option (TDSO), which is akin to an operating mode in which theperformance of the forward and/or reverse traffic channels for a remoteterminal may be tested and/or verified. The initiation and negotiationof the parameters for the TDSO are described in further detail below.While operating in this mode, test data may be transmitted over theforward and/or reverse links and over one or more traffic channels oneach link. This allows for independent testing of various trafficchannels and further allows for independent testing of the forward andreverse links.

[0043] Test Data Generation

[0044] In accordance with an aspect of the invention, various types oftest data may be used to test a traffic channel. These test data typesmay include defined data sequences, pseudo-random data, and others. Thetest data type may be selected via a parameter in the test data serviceoption.

[0045] In one test configuration, one or more defined data sequences areused to test a traffic channel. Various schemes may be used to generatethese data sequences. In one scheme, a single byte pattern is used tofill up each data block. This byte pattern may be an all ones pattern(“11111111”) or some other byte pattern. If a data block includes morethan a whole number of octets (e.g., 171 bits), each whole octet may berepresented by the byte pattern and the remaining bits may be filledwith zeros (“0”). The use of a defined data sequence may simplify thetest data generation at the transmission source and receiving device.

[0046] In another test configuration, pseudo-random data is used to testa traffic channel. This data may be generated using one or morepseudo-random number generators, as described in further detail below.

[0047]FIG. 3 is a flow diagram of a process for generating test datausing a pseudo-random number generator, in accordance with a specificembodiment of the invention. FIG. 3 presents an overall view of the testdata generation process, which is described in greater detail below.Prior to the start of each test interval for a particular trafficchannel to be tested, as determined at step 312, the pseudo-randomnumber generators used at the transmitting source and receiving deviceto generate the pseudo-random test data for this traffic channel aresynchronized and initialized, at step 314.

[0048] The pseudo-random number generator at the transmitting source isthen operated to generate a sufficient number of test data bits for Nframes (where N is two or greater), at step 316. These test data bitsare stored to a (circular) buffer, which is subsequently used as thedata source for bits to be packed into one or more data blocks for each“active” frame period in the test interval. The receiving devicesimilarly generates the test data bits for N frames, which are stored toa corresponding buffer at the receiving device and thereafter retrievedas necessary to verify whether or not the transmitted test data bits arereceived error free.

[0049] In accordance with an aspect of the invention and as describedbelow, the traffic channel may be tested using discontinuoustransmission. In this case, for each frame in the test interval, a TDSOstate for the current frame is updated, at step 318. A determination isthen made whether or not test data is to be transmitted for the currentframe based on the updated TDSO state, at step 320. If test data is tobe transmitted, one or more blocks of test data are retrieved from aparticular section of the circular buffer, at step 322. These steps aredescribed in further detail below.

[0050]FIG. 4 is a block diagram of the buffers and pseudo-random numbergenerators used for generating pseudo-random test data for a forward anda reverse traffic channel, in accordance with an embodiment of theinvention. In this embodiment, one pseudo-random number generator isassociated with each traffic channel to be tested on each of the forwardand reverse links. For example, if the TDSO is configured to transmitdata over the FCH in the forward and reverse links and over the SCHOonly in the forward link, then three pseudo-random number generators areused at the base station and three pseudo-random number generators areused at the remote terminal (only two generators are shown on each sidein FIG. 4).

[0051] In the embodiment shown in FIG. 4, base station 104 includespseudo-random number generators 440 a and 440 b used to generatepseudo-random data for a traffic channel on the forward and reverselinks, respectively. The generated test data from generators 440 a and440 b is provided to test data buffers 412 a and 412 b, respectively.Similarly, remote terminal 106 includes pseudo-random number generators480 a and 480 b used to generate pseudo-random data for the trafficchannel on the forward and reverse links, respectively, which isprovided to test data buffers 482 a and 482 b, respectively. Additionalpseudo-random number generators are used for additional traffic channelsto be tested. In an embodiment, pseudo-random number generators 440 a,440 b, 480 a, and 480 b are initialized and synchronized at eachsynchronization frame (i.e., once every test interval), as described infurther detail below.

[0052] In an embodiment, each pseudo-random number generator exhibitsthe following linear congruential relationship:

x_(x)=(a.x_(n-1)) mod m •  Eq (1)

[0053] In an embodiment, a=7⁵=16807, m=2³¹−1=2,147,483,647, and x_(n-1)and x_(n) are successive outputs of the pseudo-random number generatorand are 31-bit integers. Other values may also be used for a and m.

[0054] In an embodiment, each pseudo-random number generator isinitialized prior to each synchronization frame on the traffic channelassociate with the generator. The initialization may be achieved asfollows: { a = 16807 m = 2147483647 PRNGx = seed value // seed thegenerator PRNGx = PRNGx XOR TOGGLE // toggle some of the bits PRNGx =PRNGx AND 0x7FFFFFFF // zero out the MSB PRNGx = (aPRNGx) mod m //iterate the generator PRNGx = (PRNGx) mod m //  four times PRNGx =(aPRNGx) mod m PRNGx = (aPRNGx) mod m }

[0055] In the above pseudo-code, PRNGx denotes the content of the x^(th)pseudo-random number generator. The seed for the pseudo-random numbergenerator may be selected as the system time, in frames, of thesynchronization frame (e.g., the system frame number of thesynchronization frame may be used as the seed for the pseudo-randomgenerator). TOGGLE is a value used to toggle some of the bits of theseed, and may be selected as 0x2AAAAAAA for a generator used for theforward link and 0x55555555 for a generator used for the reverse link.As used herein, the notation “0x . . . ” denotes a hexadecimal number.

[0056] Once initiated, the pseudo-random number generator is iterated anumber of times to generate the pseudo-random test data to be used forthe upcoming test interval. The number of test data bits to be generatedis dependent on various factors such as (1) the traffic channel type(i.e., FCH, DCCH, or SCH) (2) the connected radio configuration of theremote terminal, (3) the maximum number of bits to be passed by amultiplex sublayer to the physical layer for each frame period, (4) thesize of the available buffer, and (5) possibly other factors. Themultiplex sublayer is a protocol layer between a physical layer and ahigher layer, and which multiplexes traffic data, test data, signaling,and other types of data received from the TDSO to the assigned trafficchannel(s).

[0057] In an embodiment, test data bits are generated for N frames atthe maximum bit rate possible for the connected radio configuration, asdescribed in further detail below. A default value of two, for example,may be set for N, unless another value for N is negotiated between thebase station and remote terminal. A larger value for N may provide testdata having better randomness properties but requires a larger-sizedbuffer.

[0058] After initialization, the pseudo-random number generator is usedto generate test data bits for N frames. During the test datageneration, whenever a pseudo-random number is needed, the current valueof the variable PRNGx is retrieved and used, and the variable PRNGx isthen updated (i.e., iterated) once as shown in equation (1). In anembodiment, only the most significant 24 bits of the 31-bit number forPRNGx are used because of better randomness properties and ease ofusage, and the least significant 7 bits are discarded. Thus, eachiteration of the pseudo-random number generator provides a 24-bitpseudo-random number, y_(n)(k), used to provide three bytes of testdata. P(n) iterations are performed to generate the required test datafor N frames.

[0059]FIG. 5 is a diagram that illustrates a reshuffling of eachpseudo-random number to generate 24 bits of test data. Using the 31-bitnumber from the pseudo-random number generator to generate test data isinefficient, from an implementation point of view, because the number isnot octet aligned. It is easier to build a frame with a number that isoctet aligned. The least significant bits of the 31-bit number are “lessrandom” than the most significant bits, and are thus shuffled to theright. In an embodiment, each 24-bit pseudo-random number y_(n)(k) fromthe pseudo-random number generator, where 1≦k≦P(n), is reshuffled andstored in “little-endian” order. The reshuffling is achieved by swappingthe least significant byte in the 24-bit number y_(n)(k) with the mostsignificant byte to generate the reshuffled number y_(n)^(LE)(k).

[0060] To generate test data for a new test interval for a particularrate R(n), the TDSO generates P(n) pseudo-random numbers correspondingto an actual buffer size B(n), where B(n)≧N•R(n). As an example, togenerate 344 test data bits, the pseudo-random number generator isiterated 15 times (15•24=360, which is the first integer number ofiterations that yield at least 344 bits). The buffer is then filled withthe following number sequence:y_(n)^(LE)(1), y_(n)^(LE)(2), y_(n)^(LE)(3), …  , y_(n)^(LE)(15).

[0061] The buffer is filled with test data at the start of each testinterval and prior to the synchronization frame. Thereafter, for each“active” frame in the test interval in which test data is to betransmitted, test data bits may be retrieved from the buffer to generateone or more data blocks for the frame. For a particular traffic channel,the bits from the buffer are packed serially into one or more datablocks (e.g., corresponding to the available MUX PDU (Protocol DataUnit), as determined by the connected multiplex option, where each MUXPDU represents encapsulated data communicated between peer layers at thebase station and remote terminal).

[0062] In an embodiment, the test data buffer is operated as a circularbuffer and test data for each frame is retrieved from a particularsection of the circular buffer (i.e., starting from a particularlocation in the circular buffer). Initially, after filling the circularbuffer (e.g., with at least two frames of test data), a buffer pointeris set to the first location in the buffer (e.g., address zero). In anembodiment, at the start of each frame, the pseudo-random numbergenerator is iterated once and a 24-bit number is obtained as describedabove. The least significant 6 bits of this 24-bit number, O_(n), isthen used to determine an offset for the buffer pointer. The bufferpointer is advanced from its current location by [O_(n) mod B(n)] bytepositions to the new starting location for the current frame. Bytes oftest data are then retrieved from the circular buffer, starting fromthis starting location, to fill whole octets in a data block. Forexample, if a data block includes 171 bits, then 21 bytes (i.e., 168bits) of test data are retrieved from the circular buffer and theremaining three bits in the data block are filled with zeros (“0”).

[0063] For the next frame, the pseudo-random number generator isiterated once more, the least significant 6 bits of the 24-bit number,O_(n+1), from the generator is used to determine the buffer pointeroffset for this frame. The buffer pointer is advanced by [O_(n+1) modB(n)] byte positions from the current location (which is one byteposition over from the last test data byte retrieved for the priorframe). This process for generating data blocks is repeated for eachactive frame in the test interval in which test data is to betransmitted. An example of the test data generation is provided below.

[0064] Frame and Buffer Sizes

[0065] As noted above, the pseudo-random number generator for aparticular traffic channel and (forward or reverse) link to be tested isiterated a number of times (i.e., as often as necessary) to generate thetest data to be used for a test interval. The number of test data bitsto be generated for each test interval is based on the channel type andradio configuration. Table 1 lists the maximum number of bits for each(5 msec, 20 msec, 40 msec, or 80 msec) frame and the buffer size for theFCH and DCCH for various radio configurations defined by the cdma2000standard. TABLE 1 Reverse Forward Radio Con- Radio Con- Buffer Size forBuffer Size for figuration figuration Maximum Two Frames N Frames (RC)(RC) bits/frame (bits) (bits) 1, 3, 5 1, 3, 4, 6, 172 2 × 172 = 344 N ×172 or 7 2, 4, 6 2, 5, 8, or 9 267 2 × 267 = 534 N × 267

[0066] Table 2 lists the maximum number of bits per frame and the buffersize ward supplemental channel (F-SCH0 or F-SCH1) for various radio ionsdefined by the cdma2000 standard. TABLE 2 Radio Configuration MaximumBuffer Size for Buffer Size for (RC) bits/frame Two Frames (bits) NFrames (bits) 3 3,0248 2 × 3,048 = 6,096 N × 3,048 4 6,120 2 × 6,120 =12,240 N × 6,120 5 4,584 2 × 4,584 = 9,168 N × 4,584 6 6,120 2 × 6,120 =12,240 N × 6,120 7 12,264 2 × 12,264 = 24,528 N × 12,264 8 9,168 2 ×9,168 = 18,384 N × 9,168 9 20,172 2 × 20,172 = 41,424 N × 20,172

[0067] Table 3 lists the maximum number of bits per frame and the buffersize rse supplemental channel (R-SCH0 or R-SCH1) for various radio ionsdefined by the cdma2000 standard. TABLE 3 Radio Configuration MaximumBuffer Size for Buffer Size for (RC) bits/frame Two Frames (bits) NFrames (bits) 3 6,120 2 × 6,120 = 12,240 N × 6,120 4 4,584 2 × 4,584 =9,168 N × 4,584 5 12,264 2 × 12,264 = 24,528 N × 12,264 6 20,172 2 ×20,172 = 41,424 N × 20,172

[0068] Discontinuous Transmission Testing

[0069] In accordance with an aspect of the invention, the testing of atraffic channel may be performed in a manner to model discontinuoustransmission (DTX) supported by some newer generation CDMA systems(e.g., the cdma2000 and W-CDMA systems). This DTX testing may beachieved by transmitting test data on the traffic channel in accordancewith a particular ON/OFF frame activity. For each frame period (e.g.,each 20 msec, 40 msec, or 80 msec) for the traffic channel, the TDSO maychoose to provide to the multiplex sublayer either one or more datablocks corresponding to a full-rate frame on that channel or one or moreblank data blocks. Various DTX schemes may be used to provide data tothe multiplex sublayer to achieve a particular desired frame activity.Some of these DTX schemes are described in further detail below.

[0070] In a first DTX scheme, test data is provided based on adeterministic frame activity. For this DTX scheme, test data istransmitted on the traffic channel for a particular ON duration,followed by blank data transmission for a particular OFF duration,followed by test data transmission for another ON duration, and so on.The ON and OFF durations may be selectable or negotiated between thebase station and remote terminal. Also, the ON/OFF cycles may beperiodic or non-periodic.

[0071]FIG. 6 is a diagram that illustrates test data transmission for anembodiment of the first DTX scheme. As shown in FIG. 6, the TDSO sendsto the multiplex sublayer test data blocks for a traffic channel for aparticular ON duration, and then sends blank data blocks for aparticular OFF duration. The ON/OFF cycle may be designated to start atthe beginning of a synchronization frame on the traffic channel beingtested. The ON and OFF durations may be selected such that (1) each testinterval includes one ON/OFF cycle, (2) a test interval includesmultiple ON/OFF cycles, or (3) an ON/OFF cycle spans multiple testintervals.

[0072] In an embodiment, the ON duration for transmitting test data andthe OFF duration for transmitting blank data may be specified by twoparameters (e.g., TX_ON_PERIOD and TX_OFF_PERIOD) in a message (e.g., aService Option Control Message in the cdma2000 system) sent or receivedby the transmitting source.

[0073] In a second DTX scheme, test data is provided in a pseudo-randommanner based on a particular average frame activity and burst length.This DTX scheme may be used to achieve a particular (desired orselected) long-term average of frame activity (D) and a particularaverage burst length (B) for a traffic channel. The average frameactivity D refers to the average number of frames in each ON durationversus the average number of frames in each ON/OFF cycle. And theaverage burst length B refers to the average number of frames in each ONduration.

[0074]FIG. 7 is a diagram of a two-state first-order Markov chain thatmay be used to model the ON/OFF states for the TDSO for the second DTXscheme. In an embodiment, one Markov chain is maintained for eachtraffic channel being tested. At the start of each frame, the TDSO iseither in the ON state or the OFF state. The Markov chain ischaracterized by a probability p of transitioning from the ON state tothe OFF state, and a probability q of transitioning from the OFF stateto the ON state. The values of p and q may be specified by twoparameters (e.g., ON_JTO_OFF_PROB and OFF_TO_ON_PROB) in a message(e.g., a Service Option Control Message) sent by the transmitting source(e.g., the base station).

[0075] The long-term average frame activity D may be defined as:$\begin{matrix}{D = {\frac{q}{p + q}.}} & \text{Eq (2)}\end{matrix}$

[0076] And the average burst length B may be defined as: $\begin{matrix}{B = {\frac{1}{p}.}} & \text{Eq (3)}\end{matrix}$

[0077] For some testing, it may be desirable to select the average frameactivity D and the average burst length B, and then determine thecorresponding values for p and q based on the desired D and B. Combiningand rearranging equations (2) and (3), the following are obtained:$\begin{matrix}{D = {\frac{Bq}{1 + {Bq}}.}} & \text{Eq~~(4)} \\{B = {\frac{D}{\left( {1 - D} \right)q}.}} & \text{Eq~~(5)}\end{matrix}$

[0078] Equation (4) indicates that for a given value of B, D varies from0 to B(1+B) when q varies from 0 to 1, respectively. Similarly, equation(5) indicates that for a given value of D, B varies from D/(1−D) toinfinity when q varies from 0 to 1, respectively. For example, when B isselected as 2, D should be smaller than ⅔, which indicates that theaverage frame activity D cannot be set higher than ⅔ when B is set to 2.As another example, if D is set to {fraction (7/10)}, then B is setgreater than {fraction (7/3)}.

[0079] In an embodiment, a (e.g., 24-bit) pseudo-random number is usedto drive the transition between the ON and OFF states for each frameperiod (each 5 msec, 20 msec, 40 msec, or 80 msec). In an embodiment,one pseudo-random number generator is used for all traffic channelshaving the same frame length. For example, one pseudo-random numbergenerator is used for all traffic channels having 20 msec frame length.A second pseudo-random number generator is used for supplementalchannels configured for 40 msec or 80 msec frame length, and thisgenerator is updated every 40 msec or 80 msec corresponding to thechannel frame length. In an embodiment, the pseudo-random numbergenerator(s) used to drive the TDSO states are different than the onesused to generate the test data.

[0080] In an embodiment, the pseudo-random number generator(s) used todrive the transitions between TDSO states are initialized at the startof the first synchronization frame after the TDSO is initialized. Uponinitialization, the Markov chain for each traffic channel is set to aparticular state (e.g., OFF). The pseudo-random number generator(s) arethereafter maintained throughout the duration of the call, withoutreinitialization at subsequent synchronization frames. These generatorsmay be reinitialized upon completion of a CDMA-CDMA hard handoff.

[0081]FIG. 8 is a flow diagram of an embodiment of a process fortransitioning between the ON and OFF states of the Markov chain for atraffic channel. Initially, the pseudo-random number generator used todrive the TDSO states for the traffic channel is initialized, at step812. This initialization may be achieved, for example, by obtaining aseed for the generator, XORing the seed with the value 0x2AAAAAAA,ANDing the result with the value 0x7FFFFFFF, and iterating the generatorfour times with the modified seed, as described in the abovepseudo-code.

[0082] In an embodiment, a 24-bit pseudo-random number from thepseudo-random number generator is used to determine whether or not totransition from one state to another. Thus, 24-bit ON and OFF thresholdvalues are computed, at step 814. These thresholds may be computed as:

[0083] ON_THRESHOLD=ROUND (16,777,215•q), and

[0084] OFF_THRESHOLD=ROUND (16,777,215•p).

[0085] As shown in FIG. 7, the TDSO for the traffic channel transitionsfrom the ON state to the OFF state with a probability of p, and from theOFF state to the ON state with a probability of q. Based on apseudo-randomly generated 24-bit number, the TDSO transitions from theON state to the OFF state if this number is less than the OFF_THRESHOLD,and from the OFF state to the ON state if this number is less than theON_THRESHOLD. Steps 812 and 814 are typically performed once, prior tothe first synchronization frame after the TDSO has been initialized.

[0086] The steps within box 820 are thereafter performed for each frameperiod. Initially, a 24-bit pseudo-random number is generated from thecurrent 31-bit state of the pseudo-random number generator, at step 822.A determination is next made whether or not the current TDSO state forthe traffic channel is OFF, at step 824.

[0087] If the current TDSO state is OFF, a determination is made whetherthe 24-bit number is greater than or equal to the ON_THRESHOLD, at step826. If the answer is yes, the TDSO remains in the OFF state, at step828. Otherwise, the TDSO transitions to the ON state, at step 832. Ineither case, the process then proceeds to step 834.

[0088] If the current TDSO state is ON (determined back at step 824), adetermination is then made whether the 24-bit number is greater than orequal to the OFF_THRESHOLD, at step 830. If the answer is yes, the TDSOremains in the ON state, at step 832. Otherwise, the TDSO transitions tothe OFF state, at step 828.

[0089] At step 834, the pseudo-random number generator is iterated once,as shown in equation (1), to update the state of the generator for thenext frame.

[0090] Data Block Header and Format

[0091] In accordance with an aspect of the invention, each test datablock is appropriately identified to enable concurrent testing ofmultiple traffic channels and for frames with multiple data blocks perframe. In an embodiment, the identification is achieved via a headerprovided in each data block supplied to the multiplex sublayer for eachframe.

[0092]FIG. 9 is a diagram of an embodiment of a test data block 900,which includes a channel ID field 912, a PDU (data block) sequencenumber field 914, and a test data field 916. Channel ID field 912identifies the particular traffic channel used to send this data block.PDU sequence number field 914 identifies the sequence number of thisdata block within the frame (e.g., within a physical layer service dataunit (SDU)). For a FCH or DCCH carrying one data block per frame, thisfield is set to “0”. And for an SCH capable of carrying multiple datablocks per frame, this field is set to “0” for the first data block inthe SCH frame, “1” for the second data block in the SCH frame, and soon. Test data field 916 includes the (defined or pseudo-random) testdata generated as described above.

[0093] Table 4 lists the fields and their lengths and definitions for anembodiment of test data block 900. TABLE 4 Field Length (bits)Definition Channel ID 2 Channel ID of traffic channel used to carry thedata block PDU 3 Sequence number of the data block within a Sequencephysical layer SDU Number Test Data Variable Test data bits

[0094] Table 5 shows a specific definition of the Channel ID field forvarious traffic channel types in the cdma2000 system. TABLE 5 Channel IDTraffic Channel 0 FCH 1 DCCH 2 SCH0 3 SCH1

[0095] Example of Test DAta Generation

[0096] For clarity, the test data generation is now described for aspecific example. In this example, the following parameters are used:

[0097] The TDSO is configured to transmit primary traffic over the FCH.

[0098] The base station and remote terminal are configured to supportradio configuration 3, and the frame length is 172 bits.

[0099] Multiplex option 0x01 is selected for the FCH, and one data blockis passed to the multiplex sublayer for each active (20 msec) frame.

[0100] The average frame activity D and average burst length B are basedon the probabilities p=0.7 and q=0.3. Thus, D=q/(p+q)=0.3, B=1/p≈1.4,ON_THRESHOLD=ROUND (16,777,215•p)=11,744,051, and OFF_THRESHOLD=ROUND(16,777,215•q)=5,033,164.

[0101] The least significant 32 bits of the remote terminal's PublicLong Code Mask (PLCM) is equal to 0x9F000307.

[0102] A first pseudo-random number generator used to determine thetransitions between the ON/OFF states of the Markov chain for thistraffic channel has a current value of 0x682DFF0C.

[0103] For this example, the TDSO is about to transmit frame number0xAB89EFAD on the forward FCH (F-FCH) to the remote terminal. The framenumber is XORed with the value 0x2AAAAAAA, and the least significant 9bits of the XOR result is equal to 0x107, which is equal to the leastsignificant 9 bits of the remote terminal's PLCM. This frame is thus thesynchronization frame for the F-FCH, and the test data generationprocess is resynchronized.

[0104] As part of the resynchronization, a second pseudo-random numbergenerator used to generate test data for the F-FCH is reinitialized by(1) seeding it with the frame number 0xAB89EFAD, (2) performing an XORof the seed with the value 0x2AAAAAAA to generate the value 0x01234507,and (3) iterating the pseudo-random number generator four times, asdescribed in the above pseudo-code.

[0105] After reinitialization, the state of the second pseudo-randomnumber generator is 0x3B7E3E68, the most significant 24 bits of thisstate is 0x76FC7C, and the least significant 6 bits of this 24-bitnumber is 0x3C. This 6-bit number, O_(n), is later used to determine theoffset for the circular buffer.

[0106] The second pseudo-random number generator is then iterated 15times to generate 360 test data bits for two frames of test data (15 isthe smallest number of iterations that will provide at least 344 bitsincluded in two frames for radio configuration 3). The actual buffersize is thus B(n)=45 (i.e., 360 bits=45 bytes).

[0107] The generation of the test data proceeds as follows. Prior toeach iteration, the current state of the second generator is obtainedand the most significant 24 bits are used to form a 24-bit number. Thefollowing sequence of 24-bit numbers are generated by the secondpseudo-random number generator: y_(n) (1) = 0.x76FC7C y_(n) (6) =0x4CA46B y_(n) (11) = 0xD05BFE y_(n) (2) = 0xBA6678 y_(n) (7) = 0xBE783Dy_(n) (12) = 0x478744 y_(n) (3) = 0x9D7F54 y_(n) (8) = 0xC7EDAF y_(n)(13) = 0x01A3DE y_(n) (4) = 0x1279A7 y_(n) (9) = 0xC5BDB3 y_(n) (14) =0xAD4A7D y_(n) (5) = 0xF0E8EF y_(n) (10) = 0x29428D y_(n) (15) =0xF58934

[0108] Each 24-bit number y_(n)(k) is then stored to a circular bufferfor the F-FCH in little-endian fashion, as described above. For example,the first 24-bit number 0x76FC7C is stored as 0x7CFC76, where the mostand least significant bytes of the number y_(n)(k) are swapped togenerate the reshuffled number y_(n) ^(LE)(k). The circular buffer usedto generate the data blocks for the F-FCH for the next 512 frames in thetest interval includes the following byte sequence: ↓ → 7C FC 76 78 66BA 54 7F 9D A7 79 12 EF E8 F0 6B A4 4C 3D 78 BE AF ED C7 B3 BD C5 8D 4229 FE 5B D0 44 87 47 DE A3 01 7D 4A AD 34 89 F5 →

[0109] The first pseudo-random number generator used to determine theON/OFF state is then updated, and a new 24-bit number having a value of0x478744 (4,687,684) is generated. The first pseudo-random generator isupdated at the end of the first iteration of the loop and after the24-bit number is calculated, it is tested against the ON_THRESHOLDduring the second iteration around the loop. Since this value is lessthan the ON_THRESHOLD value of 11,744,051, the TDSO transitions from theOFF state to the ON state, and a data block is provided to the multiplexsublayer for the current frame.

[0110] To generate this data block for the first frame in the testinterval, the offset for the buffer pointer is computed as O_(n) modB(n) (i.e., 0x3C mod 45=60 mod 45=15). The buffer pointer (which isinitialized to zero upon reinitialization) is thus advanced by 15 bytepositions, from 0x7C to 0x6B. The 171 bits for the data block are thenformed with 21 bytes (168 bits) retrieved from the circular buffer,starting at the buffer location identified by the advanced bufferpointer. The remaining three bits in the data block are filled withzeros. The data block includes the following byte sequence:

[0111] 6B A4 4C 3D 78 BE AF ED C7 B3 BD C5 8D 42 29 FE 5B D0 44 87 47′000′

[0112] Since this frame is to be sent over the F-FCH, the first 5 bitsof the octet are replaced by ′00000′ corresponding to the channel ID of′00′ and the PDU sequence number of ′000′. The final test data block isas follows:

[0113] 03 A4 4C 3D 78 BE AF ED C7 B3 BD C5 8D 42 29 FE 5B D0 44 87 47′000′

[0114] For the next TDSO frame, a new 24-bit number having a value of107,486 is generated by the first pseudo-random number generator. Sincethis value is less than the ON threshold, the TDSO remains in the ONstate and a new data block is generated for the multiplex sublayer.

[0115] For the second frame in the test interval, the secondpseudo-random number generator is iterated, and a 24-bit number having avalue of 0x02F3FD is generated. The 6-bit number O_(n) for the bufferoffset has a value of 0x3D. The buffer offset is then computed as O_(n)mod B(n) (i.e., 0x3D mod 15=61 mod 45=16). The buffer pointer (which waspointing one byte location over from the last retrieved byte value of0x47 for the last data block) is thus advanced by 16 byte positions from0xDE to 0x6F. The 171 bits for the data block are then formed with 21bytes from the circular buffer, starting at the new buffer location. Theremaining three bits in the data block are filled with zeros. The datablock includes the following byte sequence:

[0116] 7F 9D A7 79 12 EF E8 F0 6B A4 4C 3D 78 BE AF ED C7 B3 BD C5 8D′000′

[0117] After replacing the first 5 bits with ′00000′ corresponding tothe data block header for the F-FCH, the data block provided to themultiplex sublayer is as follows:

[0118] 07 9D A7 79 12 EF E8 F0 6B A4 4C 3D 78 BE AF ED C7 B3 BD C5 8D′000′

[0119] The buffer pointer now points to the next byte position (0x42)for the next frame.

[0120] TDSO Frame Transmission and Reception

[0121] To test a particular traffic channel, the data block(s) for each“active” frame are generated based on a defined data pattern or apseudo-random number generator, as described above. The transmittingsource and receiving device are synchronized so that the receivingdevice is able to properly generate the transmitted frames, such thatthe received frames may be compared with the locally generated frames.Each data block in each frame is appropriately identified to indicate(1) the particular traffic channel used to send the data block and (2)the data block number within the frame. The TDSO is able to compare thereceived and locally generated frames, count the errors, determine thebit error rate (BER), PDU or data block error rate (PER), and frameerror rate (FER), and compute other measures of performance.

[0122] The testing thus includes processing performed at thetransmitting source to transmit a test frame and processing performed atthe receiving device to receive a test frame.

[0123] The transmit frame processing includes:

[0124] Generating one or more data blocks for each active frame.

[0125] Supplying the generated data block(s) to the multiplex sublayerfor transmission.

[0126] Incrementing the appropriate counters.

[0127] For a test of the FCH or DCCH that operates on 20 msec frames,the TDSO provides one data block to the multiplex sublayer for eachactive frame interval in which the TDSO state for the traffic channel isON. For a test of the SCH, the TDSO provides N_(B) data blocks to themultiplex sublayer for each active frame interval (20 msec, 40 msec, or80 msec), where NB is the maximum number of data blocks in a physicallayer SDU for the connected service option. Each data block may begenerated as described above, and includes the header and test data.

[0128] The receive frame processing includes:

[0129] Generating one or more data blocks for each active frame.

[0130] Receiving data block(s) from the multiplex sublayer.

[0131] Comparing the rates and contents of the received and generateddata block(s).

[0132] Incrementing the appropriate counters.

[0133] At the receiving device, the multiplex sublayer categorizes eachreceived data block (e.g., as either test data or blank) and the frame.The multiplex sublayer then supplies the data block type and receivedtest data bits, if any, to the TDSO.

[0134] Various counters may be maintained at the transmitting source andreceiving device to support TDSO. For each traffic channel to be tested,a set of counters may be maintained at the transmitting source to keeptrack of the number of frames (of various types) and data blockstransmitted to the receiving device. At the receiving device, anotherset of counters may be maintained to keep track of the number of frames,data blocks, and data bits received from the transmitting source, thenumber of frame errors, block errors, and bit errors, and so on. Thesecounter values may be stored in a buffer. This buffer is typicallyimplemented separate from the data buffer, and is used to store variouscounters over a period of time. The counter values may thereafter beused to determine the FER, PER, and/or BER, and other statistics such asthe average frame activity, average burst length, and so on. The testresults and statistical information may be reported from the remoteterminal to the base station via one or more messages.

[0135] Test Data Service Option

[0136] In accordance with an aspect of the invention, the test dataservice option (TDSO) is a service that may be negotiated and connectedusing the available service configuration and negotiation proceduresdefined by a particular CDMA system and used for other services (e.g., avoice call, a data call). The remote terminal may be able to proposeand/or accept a service configuration having attributes that areconsistent with valid attributes for that configuration. The remoteterminal may also be able to indicate the preferred radio configurationsfor the forward and reverse links.

[0137] In an embodiment, the remote terminal is able to propose orinvoke service-option-specific functions for a TDSO call by sending amessage (e.g., a Service Option Control Message in the cdma2000 system)to the base station. This message may be sent such that anacknowledgement is requested or required from the base station. Via themessage, the remote terminal may propose values for various testparameters to be used during the test period.

[0138] The base station receives the message and may accept or rejectthe remote terminal's proposed test parameter settings. If all thefields in the remote terminal's directive are within acceptable rangesfor the base station, the base station may issue a directive thataccepts the remote terminal's proposal. This directive may be sent tothe remote terminal via a response message (e.g., a Service OptionControl Message) that includes the same values, as proposed by theremote terminal, for the various fields.

[0139] Alternatively, if the remote terminal proposes a particular testsetting not supported by or acceptable to the base station, the basestation may issue a directive that may include alternative values (i.e.,counter-proposals) to the remote terminal's proposed values. Thisdirective may be sent to the remote terminal via a response message thatincludes the proposed values in the fields supported and accepted by thebase station, and counter-proposed values in the fields not supported oraccepted by the base station. For example, if the remote terminalrequests a particular number of circular buffer frames N that is notsupported by the base station, the base station may response with avalue indicating the maximum number of frames for the buffer supportedby the base station.

[0140] Thus, via messaging and negotiation, the base station is able toaccept the remote terminal's proposal, or reject the proposal andprovide alternative values for test parameters.

[0141] Upon receiving the response message from the base station, theremote terminal may accept the counter-proposed values or select newvalues that conform to the counter-proposed values. The remote terminalmay then send to the base station another message proposing these newvalues.

[0142] Table 6 lists the valid service configuration for TDSO for aspecific implementation in the cdma2000 system. TABLE 6 ServiceConfiguration Attribute Valid Selection Forward Multiplex Option 0x01 or0x02 Reverse Multiplex Option 0x01 or 0x02 Forward Transmission RatesFor the FCH - Rates 1, ½, ¼, and ⅛ enabled For the DCCH - Rate 1enabled, Rates ½, ¼, and ⅛ not enabled Reverse Transmission Rates Forthe FCH, Rates 1, ½, ¼, and ⅛ enabled. For the DCCH, Rate 1 enabled,Rates ½, ¼, and ⅛ not enabled. Forward Traffic Type Primary or SecondaryReverse Traffic Type Should be Identical to the Forward Traffic TypeForward FCH Radio Configuration RC 1, 2, 3, 4, 5, 6, 7, 8, or 9 ReverseFCH Radio Configuration RC 1, 2, 3, 4, 5, or 6 Forward DCCH Radio RC 3,4, 5, 6, 7, 8, or 9 Configuration Reverse DCCH Radio RC 3, 4, 5, or 6Configuration Forward SCH Radio Configuration RC 3, 4, 5, 6, 7, 8, or 9Reverse SCH Radio Configuration RC 3, 4, 5, or 6 Forward SCH Frame Size20 ms, 40 ms, or 80 ms Reverse SCH Frame Size 20 ms, 40 ms, or 80 msForward Supplemental Channel 0x921, 0x911, 0x909, 0x905, 0x821,Multiplex Option 0x811, 0x809, 0x03 0x922, 0x912, 0x90a, 0x906, 0x822,0x812, 0x80a, 0x04, 0xf20 Reverse Supplemental Channel 0x921, 0x911,0x909, 0x905, 0x821, Multiplex Option 0x811, 0x809, 0x03 0x922, 0x912,0x90a, 0x906, 0x822, 0x812, 0x80a, 0x04, 0xf20

[0143] As noted above, a number of traffic channels may be concurrentlytested on each of the forward and reverse links. For each trafficchannel to be tested, the test parameters for the channel may benegotiated via the signaling and negotiation described above. Thus,traffic channels of various types on the forward and reverse links maybe tested independently based on their respective sets of test parametervalues.

[0144] In FIGS. 2A, 2B, and 4, the elements in the base station andremote terminal may be implemented by various means. For example, thepseudo-random number generators may be implemented with hardware,software, or a combination thereof. For a hardware implementation,pseudo-random number generators, controllers, and other processing unitsmay be implemented within one or more application specific integratedcircuits (ASICs), digital signal processors (DSPs), programmable logicdevices (PLDs), controllers, micro-controllers, microprocessors, otherelectronic units designed to perform the functions described herein, ora combination thereof.

[0145] For a software implementation, these processing units may beimplemented with modules (e.g., procedures, functions, and so on) thatperform the functions described herein. For example, the pseudo-randomnumber generators may be implemented with software code stored in amemory unit and executed by a processor (e.g., controller 220 or 270).

[0146] The circular buffers for the test data for the traffic channelsmay be implemented with one or more buffers, which may be implementedusing RAM, DRAM, Flash memory, or some other memory technology. Also,the pseudo-random number generators may be operated to generate testdata for the traffic channels as the data is needed, without having tostore the test data in buffers. In that case, the states of thepseudo-random number generators are appropriately maintained and updatedsuch that the generators are able to generate the proper sequence oftest data for each active frame.

[0147] Although various aspects, embodiments, and features of the testdata generation and traffic channel testing of the invention have beendescribed for the cdma2000 system, these techniques may beadvantageously applied for the other wireless communication systems andother CDMA systems (e.g., the W-CDMA system).

[0148] A specific implementation of various aspects of the invention fora cdma2000 system is described in the following Exhibit A. EXHIBIT ATR45 TEST DATA SERVICE OPTION (TDSO) for cdma2000 Spread SpectrumSystems PN-4877 Ballot Version November 13, 2000 Contents FOREWORD 38NOTES 39 REFERENCES 41 1 General 42  1.1 Terms 42  1.2 Notation 44 2Test Data Service Option 45  2.1 Overview 45  2.2 General description 46 2.3 Service option number 47  2.4 Required multiplex option support 47  2.4.1 Multiplex option support for FCH/DCCH (for 20 ms 47   FCH/DCCHframes only)   2.4.2 Multiplex option support for SCH 48  2.5 Interfaceto multiplex options 49  2.6 Primary traffic 49   2.6.1 Secondarytraffic 51  2.7 TDSO frame transmission and reception 53   2.7.1Transmitted frames 54   2.7.2 Received frames 30  2.8 Interface to Layer3 Signaling when testing 5 ms 55  FCH/DCCH frames 3 TDSO Procedures andDescription 56  3.1 Negotiation and activation of service option 56  3.1.1 Mobile station requirements 56    3.1.1.1 Supplemental channelallocation 58    3.1.1.2 CDMA-CDMA hard handoff scenario 62   3.1.2 Basestation requirements 63  3.2 Synchronization frame 63   3.2.1 ForwardTraffic Channels 64   3.2.2 Forward Supplemental Channels 64   3.2.3Reverse Traffic Channels 64   3.2.4 Reverse Supplemental Channels 64 3.3 Counters 65  3.4 Mobile station initialization and controloperation 68   3.4.1 Service option initialization 68   3.4.2 Mobilestation control operations 70    3.4.2.1 Control invocation 70   3.4.2.2 Control directive 70    3.4.2.3 Counter retrieval 72  3.5Base station initialization and control operations 73    3.5.1.1 Controlinvocation 73    3.5.1.2 Control directive 73    3.5.1.3 Counterretrieval 74  3.6 TDSO Frame processing 74  3.6.1 Transmit frameprocessing 75  3.6.2 Receive frame processing 78  3.6.3 Transmit frameprocessing for 5 ms FCH/DCCH frames 82    3.6.3.1 Mobile StationRequirement 82    3.6.3.2 Base Station Requirement 83  3.7 TDSO framegeneration 84   3.7.1 Selectable byte pattern 84   3.7.2 Pseudo-randomnumber generation 85    3.7.2.1 Initialization 87    3.7.2.2 Numberproduction 88    3.7.2.3 24-bit random number 89   3.7.3 Circular buffersizes 89   3.7.4 Information bit generation 91   3.7.5 Frame activity 93   3.7.5.1 Deterministic frame activity 93    3.7.5.2 Random with aspecified frame activity and burst 94    length   3.7.6 Data blockheader and formats 97  3.8 Message formats 98   3.8.1 Service OptionControl Message 98    3.8.1.1 Control 99    3.8.1.2 Counter retrieval104    3.8.1.3 Counter responses on the fundicated channels 106   3.8.1.4 Receive Expected Counters Response 109    3.8.1.5 TransmittedCounters Response 112    3.8.1.6 5 ms Frame Transmitted CountersResponse 114    3.8.1.7 5 ms Frame Received Counters Response 115  3.8.2 Counter responses on the Supplemental Channels 117    3.8.2.1FER counters response 117    3.8.2.2 PER Counters Response 119   3.8.2.3 Transmitted Counters response 123 ANNEX A TDSO Call FlowExamples (for a system operating in 124 MC-41 mode) ANNEX B TDSOOperation Examples 128 ANNEX C Using the TDSO 147 ANNEX D Calculating pand q Based on D and B 153 Figures FIG. 1. Synchronized operation ofpseudo-random number 86 generated buffers FIG. 2. Reshuffling of y_(n)(k) to generate y_(n) ^(LE) (k) 92 FIG. 3. Two-state Markov chainrepresenting ON/OFF 95 transitions for TDSO FIG. 4. Flowchartillustrating TDSO state transitions for a D 96 frame activity and Baverage “On” period in units of frames FIG. 5. Mobile stationorigination example with transmission 125 on DCCH/FCH/SCH (part 1 of 2)FIG. 6. Mobile station origination example with transmission 127 onDCCH/FCH/SCH (part 2 of 2) FIG. 7. Base station commanded testparameters change 128 Tables Table 1. Summary of test data serviceoption notation 44 Table 2 Multiplex option support for FCH or DCCH 47Table 3 Multiplex options applicable to an SCH 48 Table 4 Primarytraffic types supplied by the TDSO to the 49 multiplex sublayer Table 5.Primary traffic frame types supplied by the multiplex 50 layer to TDSOTable 6 Secondary traffic frames supplied by TDSO to the 51 multiplexsublayer Table 7. Secondary traffic frames supplied by multiplex 52sublayer to the TDSO Table 8 Valid service configuration attributes fortest data 56 service option Table 9 SCRM_REQ_BLOB format 60 Table 10SCRMM_REQ_BLOB format 61 Table 11 Encoding of the PREFERRED_RATE field62 Table 12 Encoding of the DURATION field 62 Table 13 Transmit framecounters on the fundicated channel 65 Table 14 Transmitted framecounters on the Supplemental 65 Channel Table 15 Receive frame countersmaintained for the 66 FCH/DCCH Table 16 Receive frame counters on theSupplemental Channel 66 Table 17 Receive PDU counters maintained for the67 Supplemental Channels Table 18 Frame counter-value storage 67 Table19 Frame counter-value storage for Supplemental 68 Channels Table 20Counters for fundicated transmitted frames 77 Table 21 Counters forsupplemental transmitted frames 78 Table 22 Counter updates for receivedfundicated frames when 79 MuxPDU Type 1 is used Table 23 Counter updatesfor received fundicated frames when 80 MuxPDU Type 2 is used Table 24Counter updates for PDUs received on Supplemental 81 Channels Table 25Counter updates for received frames on Supplemental 82 Channels Table 26Circular buffer sizes needed to generate fundicated 90 channel dataframes Table 27 Circular buffer sizes needed to generate reverse 90Supplemental Channel data frames Table 28 Circular buffer sizes neededto generate forward 91 Supplemental Channel data frames Table 29Procedure for generating the default circular buffers 93 for RC > 2channels Table 30 Data block format 97 Table 31 CHANNEL_ID type codes 98Table 32 CTL_REC_TYPE codes 98 Table 33 Service Option Control Messagetype-specific fields 99 Table 34 CONTROL_CODE codes 102 Table 35DATA_SOURCE codes 103 Table 36 FRAME_ACTIVITY codes 103 Table 37CHANNEL_DIRECTION codes 103 Table 38 FRAME_SOURCE codes 103 Table 39TEST_OPTIONS codes 104 Table 40 Type-specific fields in a Service OptionControl 104 Message used for counter retrieval on the FCH/DCCH Table 41VECT_COUNTER_ID codes for FCH/DCCH 105 Table 42 Type-specific fields ina Service Option Control Message 105 used for counter retrieval from themobile station for SCHs Table 43 VECT_COUNTER_ID codes for SCHs 105Table 44 Type-specific fields in a Service Option Control 107 Messagecorresponding to FER Counters Response on FCH/DCCH Table 45Type-specific fields in a Service Option Control 109 Messagecorresponding to Receive Expected Counters Response on FCH/DCCH Table 46Type-specific fields in a Service Option Control 112 Messagecorresponding to Transmitted Counters Response on FCH/DCCH Table 47Type-specific fields in a Service Option Control 115 Messagecorresponding to 5 ms Frame Transmitted Counters Response on FCH/DCCHTable 48 Type-specific fields in a Service Option Control 116 Messagecorresponding to 5 ms Frame Received Counters Response on FCH/DCCH Table49 Type-specific fields in a Service Option Control 117 Messagecorresponding to FER Counters Response on SCH(s) Table 50 Type-specificfields in a Service Option Control 119 Message corresponding to PERCounters response on SCH(s) Table 51 Type-specific fields in a ServiceOption Control 123 Message corresponding to Transmitted Countersresponse on SCH(s)

FOREWORD

[0149] This document specifies procedures for the Test Data ServiceOption (TDSO). The TDSO is used to allow verification of the physicallayer performance frame error rate (FER) and PDU error rate (PER) ofcdma2000 physical channels.

[0150] The document is organized into the following sections:

[0151] Chapter 1 defines the terms and notations used in this document.

[0152] Chapter 2 outlines the requirements of the TDSO and provides ageneral description of the TDSO.

[0153] Chapter 3 describes the detailed procedures and operation of themobile station and the base station for the TDSO.

[0154] Annex A is an informative section that presents some TDSO callflow examples.

[0155] Annex B is an informative section that presents some TDSO framegeneration examples.

[0156] Annex C is an informative section that presents some proceduresfor conducting a TDSO test. It also shows the use of the transmitcounters and the receive counters for estimating the FER and PER for theForward and Reverse Traffic Channels.

[0157] Annex D is an informative section that presents the equations forcalculating transition probabilities p and q based on average frameactivity (D) and average burst length (B).

NOTES

[0158] “Base station” refers to the functions performed on the landlineside, which are typically distributed among a cell, a sector of a cell,and a mobile switching center.

[0159] The following verbal forms: “Shall” and “shall not” identifyrequirements to be followed strictly to conform to the standard and fromwhich no deviation is permitted. “Should” and “should not” indicate thatone of several possibilities is recommended as particularly suitable,without mentioning or excluding others; that a certain course of actionis preferred but not necessarily required; or that (in the negativeform) a certain possibility or course of action is discouraged but notprohibited. “May” and “need not” indicate a course of action permissiblewithin the limits of the standard. “Can” and “cannot” are used forstatements of possibility and capability, whether material, physical, orcausal.

[0160] Footnotes appear at various points in this specification toelaborate and further clarify items discussed in the body of thespecification.

[0161] Unless indicated otherwise, this document presents numbers indecimal form.

[0162] Binary numbers are distinguished in the text by the use of singlequotation marks. In some tables, binary values may appear without singlequotation marks if the table notation clearly specifies that values arebinary. The character ′x′ is used to represent a binary bit ofunspecified value. For example ′xxx00010′ represents any 8-bit binaryvalue such that the least significant five bits equal ′00010′.

[0163] Hexadecimal numbers (base 16) are distinguished in the text byuse of the form 0xh . . . h where h . . . h represents a string ofhexadecimal digits. For example, 0x2fa1 represents a number whose binaryvalue is ′10111110100001′ and whose decimal value is 12193. Note thatthe exact number of bits in the binary representation of a hexadecimalnumber strictly depends on the implementation requirements for thevariable being represented.

[0164] The following conventions apply to mathematical expressions inthis standard:

[0165] └x┘ indicates the largest integer less than or equal to x:└1.1┘=1, └1┘=1.

[0166] ┌x┐ indicates the smallest integer greater than or equal to x:┌1.1┐=2, ┌2.0┐=2.

[0167] ROUND(x) indicates the integer that is closest to x:ROUND(1.2)=1, ROUND(1.9)=2.

[0168] |x| indicates the absolute value ofx: |−17|=17, |17|=17.

[0169] min(x, y) indicates the minimum of x and y.

[0170] max(x, y) indicates the maximum of x and y.

[0171] In figures, x indicates multiplication. In formulas within thetext, multiplication is implicit. For example, if h(n) and p_(L)(n) arefunctions, then h(n) p_(L)pk (n)=h(n)×p_(L)(n).

[0172] x mod y indicates the remainder after dividing x by y: x mody=x−(y └x/y┘).

[0173] x ∈{a, b, c } indicates x is a member of the set comprised ofelements a, b, and c.

[0174] The bracket operator, [ ], isolates individual bits of a binaryvalue.

[0175] VAR[n] refers to bit n of the binary representation of the valueof the variable VAR, such that VAR[0] is the least significant bit ofVAR. The value of VAR[n] is either 0 or 1.

[0176] x≈y indicates that x is approximately equal to y.

[0177] The following conventions apply to expressions in the pseudo codein this standard:

[0178] x & y represents the bit-wise AND operation between the binaryrepresentation of x and y: 31 & 4=4=′00100′.

[0179] x>y represents the bit-wise exclusive OR operation between thebinary representation of x and y: 31>4=27=′11011′.

[0180] x>>k represents the bit-wise right shift of x by k bits with thevacated positions at the left filled with ′0′ bits: 61>>3=7=′000111′.

[0181] x<<k represents the bit-wise left shift of x by k bits withvacated positions at the right filled with ′0′ bits: 4<<3=32=′100000′.

[0182] ++represents an increment operator: x++increments the value of xby 1.

[0183] The symbols (* and *) are used to enclose comments.

[0184] This document applies only to base stations with P_REV equal toor greater than 6, and to mobile stations with MOB_P_REV equal to orgreater than 6 and.

[0185] This document supports systems operating in MC-MAP mode.

REFERENCES

[0186] The following standards contain provisions which, throughreference in this text, constitute provisions of this Standard. At thetime of publication, the editions indicated were valid. All standardsare subject to revision, and parties to agreements based on thisStandard are encouraged to investigate the possibility of applying themost recent editions of the standards indicated below.

[0187] Standards:

[0188] 1. Reserved.¹

[0189] 2. TIA/EIA/IS-2000.2-A, Physical Layer Standardfor cdma2000Spread Spectrum Systems.

[0190] 3. TIA/EIA/IS-2000.3-A, Medium Access Control Standardforcdma2000 Spread Spectrum Systems.

[0191] 4. Reserved.²

[0192] 5. TIA/EIA/IS-2000.5-A, Upper Layer (Layer 3) Signaling Standardfor cdma2000 Spread Spectrum Systems.

[0193] 6. TIA/EIA/IS-833, Multi-Carrier Specification for SpreadSpectrum on GSM MAP (MC-MAP).

General

[0194] Terms

[0195] Base Station (BS). A fixed station used for communicating withmobile stations. Depending on the context, the term base station mayrefer to a cell, a sector within a cell, or another part of the wirelesssystem.

[0196] Blank-and-burst. The preemption of the traffic in an entiretraffic channel frame by another form of traffic, typically signaling.

[0197] Data Block. The unit of data exchanged between the multiplexsublayer and the TDSO.

[0198] Dim-and-burst. A frame in which primary traffic is multiplexedwith secondary, signaling, or secondary and signaling traffic.

[0199] ESCAM. Extended Supplemental Channel Assignment Message (see[5]).

[0200] FER. Frame Error Rate.

[0201] Forward Dedicated Control Channel. A portion of a RadioConfiguration 3 through 9 Forward Traffic Channel.

[0202] Forward Fundamental Channel. A portion of a Forward TrafficChannel.

[0203] Forward Supplemental Channel. A portion of a Radio Configuration3 through 9 Forward Traffic Channel, which operates in conjunction witha Forward Fundamental Channel or Forward Dedicated Control Channel inthat Forward Traffic Channel to provide higher data rate services.

[0204] Forward Traffic channel. One or more forward CDMA channels usedto transport user and signaling traffic from the base station to themobile station (see Forward Fundamental Channel, Forward DedicatedControl Channel, and Forward Supplemental Channel).

[0205] Frame. A basic timing interval in the system. For the trafficchannel, a frame is 5 ms, 20 ms, 40 ms, or 80 ms long.

[0206] FSCAMM. Forward Supplemental Channel Assignment Mini Message (see[5]).

[0207] Fundamental Channel. A portion of a traffic channel, whichincludes a Forward Fundamental Channel and a Reverse FundamentalChannel.

[0208] Fundicated Frame. A TDSO frame carried in a fundicated datablock.

[0209] Fundicated Channel. Fundamental Channel or a Dedicated ControlChannel.

[0210] Fundicated Data Block. A data block carried on a FundamentalChannel or a Dedicated Control Channel.

[0211] Mobile Station (MS). A station that communicates with the basestation.

[0212] Multiplex Format Indicator. A number that specifies the format ofa MuxPDU [see 3].

[0213] Multiplex Option. The ability of the multiplex sublayer and lowerlayers to be tailored to provide special capabilities. A multiplexoption defines such characteristics as the frame format and ratedecision rules (see also Multiplex Sublayer).

[0214] Multiplex Sublayer. One of the conceptual layers of the systemthat multiplexes and demultiplexes primary traffic, secondary traffic,and signaling traffic (see [3).

[0215] MuxPDU Type 1 Category. The category of the received MuxPDU type1 as defined in [3].

[0216] MuxPDU Type 2 Category. The category of the received MuxPDU type2 as defined in [3].

[0217] MuxPDU Type 3 Category. The category of the received MuxPDU type3 as defined in [3].

[0218] MuxPDU Type 5 Category. The category of the received MuxPDU type5 as defined in [3].

[0219] PER. PDU Error Rate.

[0220] Primary Traffic. Data bits from a service that has the traffictype in the Service Configuration Record set to Primary.

[0221] Radio Configuration (RC). A set of Forward Traffic Channel andReverse Traffic Channel transmission formats that are characterized byphysical layer parameters such as transmission rates, modulationcharacteristics, and spreading rate.

[0222] Reverse Dedicated Control Channel. A portion of a RadioConfiguration 3 through 6 Reverse Traffic Channel.

[0223] Reverse Fundamental Channel. A portion of a Reverse TrafficChannel.

[0224] Reverse Supplemental Channel. A portion of a Radio Configuration3 through 6 Reverse Traffic Channel, which operates in conjunction witha Reverse Fundamental Channel or Reverse Dedicated Control Channel inthat Reverse Traffic Channel to provide higher data rate services.

[0225] Reverse Traffic channel. One or more reverse CDMA channels onwhich data and signaling are transmitted from a mobile station to a basestation (see Reverse Dedicated Control Channel, Reverse FundamentalChannel, and Reverse Supplemental Channel).

[0226] RSCAMM. Reverse Supplemental Channel Assignment Mini Message (see[5]).

[0227] SCRM. Supplemental Channel Request Message (see [5]).

[0228] SCRMM. Supplemental Channel Request Mini Message (see [5]).

[0229] Secondary Traffic. Data bits from a service that has the traffictype in the Service Configuration Record set to Secondary.

[0230] Service Option. A service capability of the system. Serviceoptions may be applications such as voice, data, or facsimile etc.

[0231] Service Option Connection. A particular instance or session inwhich the service defined by a service option is used.

[0232] Signaling Traffic. Control messages that are carried betweenmobile station and the base station on the Traffic Channel.

[0233] System Time. The time reference used by the system. System Timeis synchronous to Universal Coordinate Time (except for leap seconds)and uses the same time origin as GPS time. All base stations use thesame System Time (within a small margin of error). Mobile stations usethe same System Time, offset by the propagation delay from the basestation to the mobile station.

[0234] TDSO. Test Data Service Option.

[0235] Traffic Channel. One or more CDMA channels on which data andsignaling are transmitted between a mobile station and base station (seeForward Traffic Channel and Reverse Traffic Channel).

[0236] UHDM. Universal Handoff Direction Message (see [5]).

[0237] Notation

[0238] The TDSO uses the notation as listed in Table 7. TABLE 7 Summaryof test data service option notation Sec- Parameter tionName/Description B(n) 0 Actual circular buffer size FRNG 0 State of theForward Traffic Channel pseudo-random number generator NUM_RAND 0 Numberof pseudo-random number generations per frame to generate informationbits in a data block or data blocks R(n) 0 Needed circular buffer sizeRRNG 0 State of the Reverse Traffic Channel pseudo-random numbergenerator X_(n) 0 Pseudo-random number generated by the linearcongruential generator y_(n)(k) 0 A 24-bit pseudo-random number used forthe generation of circular buffer information bits Y_(n) ^(LE)(k) 0 Anumber derived from y_(n)(k) after storing it in little endian orderO_(n) 0 A 6-bit pseudo-random number used for determining the next byteoffset in the circular buffer

Test Data Service Option

[0239] Overview

[0240] The following are the requirements of the cdma2000 Test DataService Option:

[0241] Connects the Service Option at the Multiplex Sublayer.

[0242] Supports both forward and reverse links (asymmetric andsymmetric).

[0243] Does bit-wise comparison of the received frame with the locallygenerated/expected frame to detect the undetected bit errors that arenot detected by frame quality bits.

[0244] Maintains separate sets of error statistics for the FCH/DCCH andSCH(s) and responds with this information when queried by the basestation.

[0245] Defines a single service option, and sets up different RCs andservice configurations on the two links through service negotiation.

[0246] May include simultaneous primary and secondary traffic (forexample, can run Markov service [SO 54] on the Fundamental Channel andTDSO on the Supplemental Channel).

[0247] Can be carried by all RC combinations on the reverse/forwardlinks as defined under cdma2000.

[0248] Requires separate channel IDs to differentiate between the FCH,DCCH, and Supplemental Channel(s).

[0249] Is able to handle multiframe interleaving over 40 ms and 80 msintervals in the physical layer.

[0250] Does not preclude a future extension to support flexible/variablerate.

[0251] Allows two types of ON/OFF traffic models to be selectable:

[0252] Deterministic frame activity given by TX_ON and TX_OFF

[0253] Random frame activity with average frame activity D and averageburst length B, in units of Physical Layer frames

[0254] Supports two source types of bits for frame generation:

[0255] Selectable byte pattern

[0256] Pseudo-random bits

[0257] Supports 5 ms FCH/DCCH frames testing using Layer 3 Signalingmini messages

[0258] General description

[0259] TDSO provides for the generation of an arbitrary (preselected orrandom) data source for transport over forward and reverse trafficchannels while following an arbitrary (preselected or random)transmission frame activity. The test is performed at a fixed data rate.

[0260] The mobile station and the base station generate TDSO data framesfor the configured and allocated traffic channels. The content of eachframe is generated per a selectable byte pattern or by employing ahybrid approach consisting of pseudo-randomly generated data togetherwith a circular buffer.

[0261] The frame generation processes are synchronized between themobile station and the base station. This permits the receiving stationto reproduce the transmitted frames and compare them to the receivedframes. The TDSO counts the number of various frame types that weretransmitted on a particular traffic channel. The TDSO also counts thenumber of various frame types received on the traffic channel accordingto the information provided by the multiplex sublayer and the result ofthe comparison between the frame received and the locally generatedreplica. Frame error and bit error statistics can be calculated fromthese counts.

[0262] The TDSO allows system signaling to take precedence.Dim-and-burst frames and blank-and-burst frames are excluded from FER orbit error rate calculations. Because the receiver cannot predict whenthe transmitter transmits a dim-and-burst or blank-and-burst frame, thereceiver may categorize a frame as dim-and-burst or blank-and-burst whenit is not (false alarm), or categorize a frame as not dim-and-burst orblank-and-burst when it is (miss). Therefore, the frame error statisticscalculated by using only frame counts recorded in the receiver may notbe exact. However, the error is very small and can usually be ignored.

[0263] Service option number

[0264] The TDSO described by this standard shall use service optionnumber 32.

[0265] Required multiplex option support

[0266] The TDSO shall transmit and receive traffic channel frames inaccordance with the requirements of the multiplex option or multiplexoptions configured for the service option.

[0267] Multiplex option support for FCH/DCCH (for 20 ms FCH/DCCH framesonly)

[0268] On the FCH/DCCH physical channels, the TDSO shall support aninterface with the multiplex options indicated in Table 8. TABLE 8Multiplex option support for FCH or DCCH Multiplex Option Forward RC =1, 3, 4, 6, or 7 Forward RC = 2, 5, 8, or 9 Reverse RC = 1, 3, or 5Reverse RC = 2, 4, or 6 FCH/DCCH 0 × 1 0 × 2

[0269] When Multiplex Option 0x01 is used, MuxPDU Type 1 is used (see0for interface to multiplex option).

[0270] When Multiplex Option 0x02 is used, MuxPDU Type 2 is used (see0for interface to multiplex option)

[0271] Multiplex option support for SCH

[0272] On the SCH(s) physical channel(s), the TDSO shall support aninterface with the multiplex options as indicated in Table 9. TABLE 9Multiplex options applicable to an SCH Maximum number of MuxPDUs in thephysical Multiplex option layer SDU Forward RC = 3, 4, 6, or 7 ForwardRC = 5, 8, or 9 MuxPDU Reverse RC = 3 or 5 Reverse RC = 4 or 6 Type 1MuxPDU Type 3 MuxPDU MuxPDU Type 3 MuxPDU MuxPDU Type 3 SCH Rate or 2Single Double Type 1 Single Double Type 2 Single Double 1× 1 0 × 03 0 ×04 2× 2 1 0 × 809 0 × 905 0 × 80a 0 × 906 4× 4 2 0 × 811 0 × 909 0 × 8120 × 90a 8× 8 4 0 × 821 0 × 911 0 × 822 0 × 912 16× 8 0 × 921 0 × 922

[0273] The SCH rate is expressed in multiples of a base rate. Forexample, odd multiplex options have the base rate 9600 bps, a 2x SCHrate means twice of 9600 bps or 19200 bps. For Supplemental Channelrates lower than or equal to 16x, MuxPDU Type 1, 2 or 3 that isassociated with the multiplex option as shown in Table 9 will be used.For Supplemental Channel rates higher than 16x, the TDSO shall useMuxPDU Type 5, which is associated with the Multiplex Option 0xf20.

[0274] The number of data blocks (either carried by MuxPDU Type 1, 2, or3) in every SCH frame is shown in Table 9 for different multiplexoptions. For SCH rates higher than 16x, there is exactly one data block(carried by MuxPDU Type 5) in every SCH frame (see [3]). (see Oforinterface to multiplex options)

[0275] Interface to multiplex options

[0276] TDSO frames can be carried as primary or secondary traffic.

[0277] A TDSO frame supplied to the multiplex sublayer as a fundicateddata block (a data block carried on an FCH or DCCH) is called aFundicated TDSO frame. Similarly, a TDSO frame supplied to the multiplexsublayer to be carried as a supplemental data block or data blocks (datablock(s) carried on an SCH0 or SCH1) is referred to as a SupplementalTDSO frame.

[0278] Primary traffic

[0279] Normally, each TDSO frame supplied to the multiplex sublayershall be one of the Rate 1, Rate 2, or Blank (zero bits) frame typesshown in Table 10. Table 10. The number of bits per data block suppliedto the multiplex sublayer for each type of TDSO frame is shown in Table10. The maximum number of MuxPDUs (or data blocks) that can be carriedin an SCH TDSO frame is also shown in Table 9.

[0280] On command, the TDSO shall supply a Blank frame. A Blank framecontains no bits. Also on command, the TDSO shall supply a non-blankFundicated TDSO frame of x bits when the multiplex sublayer requests foran x-bit data block. The first x bits of the generated Fundicated TDSOframe shall be supplied to the multiplex sublayer. TABLE 10 Primarytraffic types supplied by the TDSO to the multiplex sublayer Can beOdd-numbered Even-numbered Can be supplied as a TDSO multiplex multiplexsupplied as a Supple- frame option (bits per option (bits per Fundicatedmental type data block) data block) TDSO frame TDSO frame Rate 3¹ N/AVariable No Yes  Rate 2  346 538 No Yes² Rate 1  171 266 Yes Yes³ 170266 No Yes⁴ Blank  0  0 Yes Yes 

[0281] The multiplex sublayer in the mobile station categorizes everyreceived MuxPDU(s) in the Traffic Channel frame and supplies the MuxPDUcategory and accompanying bits, if any, to TDSO. When the multiplexformat indicator is supplied by the mux sublayer, the value of themultiplex format indicator shall be used as the MuxPDU category.

[0282] Table 11 lists the categories (and corresponding TDSO frametypes) supplied by the multiplex sublayer when TDSO is carried asprimary traffic. TABLE 11 Primary traffic frame types supplied by themultiplex layer to TDSO Odd-numbered Even-numbered multiplex optionsmultiplex options Bits Categories Categories Bits Categories CategoriesTDSO per for for sup- per for for sup- frame data fundicated plementaldata fundicated plemental type block MuxPDU MuxPDU block MuxPDU MuxPDURate 3 N/A N/A N/A Vari- N/A 2 able Rate 2 346 N/A 5 538 N/A 5 Rate 1171 1 1 266  1 1 170 N/A 4 266 N/A 4 Blank  0 5, 14 2  0 5, 9, 14, 2 17, 21, 23, 25 Null  0 15 N/A  0 27 N/A

[0283] Secondary traffic

[0284] Normally, each TDSO frame supplied to the multiplex sublayershall be one of the Rate 1, Rate 2, Rate 3, or Blank frame types shownin. The number of bits per data block supplied to the multiplex sublayerfor each type of TDSO frame shall also be as shown in Table 12. Themaximum number of MuxPDUs that can be carried in a SCH TDSO frame isalso shown in Table 9.

[0285] On command, TDSO shall generate a Blank TDSO frame. A Blank TDSOframe contains no bits. Also on command, TDSO shall supply a non-blankFundicated TDSO frame of x bits when the multiplex sublayer requests foran x-bit data block. The first x bits of the generated Fundicated TDSOframe shall be supplied as a data block to the multiplex sublayer. TABLE12 Secondary traffic frames supplied by TDSO to the multiplex sublayerCan be Odd-numbered Even-numbered Can be supplied as a TDSO multiplexmultiplex supplied as a Supple- frame option (bits per option (bits perFundicated mental type data block) data block) TDSO frame TDSO frameRate 3¹ N/A Variable No Yes  Rate 2  346 538 No Yes² Rate 1  168 262 YesYes³ 170 266 No Yes⁴ Blank  0  0 Yes Yes 

[0286] The multiplex sublayer in the mobile station categorizes everyMuxPDU in the received Traffic Channel frame and supplies the MuxPDUcategory and accompanying bits, if any, to TDSO. When the multiplexformat indicator is supplied by the mux sublayer, the value of themultiplex format indicator shall be used as the MuxPDU category. Table13 lists the categories (and corresponding TDSO frame types) supplied bythe multiplex sublayer when the TDSO is carried as secondary traffic.TABLE 13 Secondary traffic frames supplied by multiplex sublayer to theTDSO Odd-numbered Even-numbered multiplex options multiplex options BitsCategories Categories Bits Categories Categories TDSO per for for sup-per for for sup- frame data fundicated plemental data fundicatedplemental type block MuxPDU MuxPDU block MuxPDU MuxPDU Rate 3 N/A N/AN/A Vari- N/A 2 able Rate 2 346 N/A 5 538 N/A 5 Rate 1 168 14 2 262  9 2170 N/A 4 266 N/A 4 Blank  0 1-8 1  0 1-5, 1 11-14, 19-21, 24 Null  0 15N/A  0 27 N/A

[0287] TDSO frame transmission and reception

[0288] When primary or secondary traffic is carried on SCH(s) and/orFCH/DCCH, the content of each frame is generated in one of two ways, asnegotiated between the two ends. The test stream can consist of aselectable repeated byte pattern (by default set to all 1's) or apseudo-randomly generated data stream from a circular buffer. The twoends are synchronized to the content of test data transmitted (expected)in a particular frame. This permits the receiving station to reproducethe transmitted frames and compare them to the received frames. When apseudo-random data stream is used, data blocks for all frames aregenerated by copying the bits from the circular buffer to the datablocks, starting at a random offset for each TDSO frame. The randomoffset is synchronized between the mobile station and the base station.

[0289] The TDSO counts the number of various frame types received on theFCH/DCCH and/or SCH separately according to the MuxPDU categoryinformation provided by the multiplex sublayer and the result of thecomparison between the frames received and the locally generatedreplica. FER and PER characteristics can be calculated from these countsfor each physical channel.

[0290] There can be instances of transmission power headroom running outin either the base station or mobile station (causing the transmitter tonot transmit on a given traffic channel for a particular frame), whichleads to the physical layer reporting an erasure at the receiver. Forthe TDSO, no special mechanism is used to account for the inaccuraciesthat can occur in the FER (PER) calculation due to this. No transmissionby the physical channel is considered to be a channel and/orimplementation limitation.

[0291] Transmitted frames

[0292] If configured to operate over Fundicated Channels (FCH or DCCH)that use 20 ms frames, if the frame activity is “ON”, the service optionshall supply exactly one Fundicated data block to the multiplex sublayerevery 20 ms. The data block contains a header (channel ID and PDUsequence number) followed by the service option information bits. posUnless otherwise commanded, the service option shall supply a Rate 1 orblank data block as listed in Table 10 and Table 12 when carryingprimary or secondary traffic, respectively. On command, the serviceoption shall supply a blank data block. Also on command, the serviceoption shall supply a data block with the number of bits that themultiplex sublayer requests, by truncating the generated data block ifnecessary.

[0293] If configured to operate over Supplemental Channels (SCH0 and/orSCH1), if the frame activity is “ON”, the service option shall supplyone or N data blocks to the multiplex sublayer for each SupplementalChannel every frame interval (20 ms, 40 ms, or 80 ms), where N is themaximum number of data blocks (or MuxPDUs) in a physical layer SDU for aconnected multiplex option, as shown in Table 9. The data blocks containa header (channel ID and PDU sequence number) followed by the serviceoption information bits.

[0294] Unless otherwise commanded, the service option shall supply Rate1, Rate 2, Rate 3, or Blank Supplemental frames, as listed in Table 10and Table 12, when carrying primary or secondary traffic, respectively.A single data block is passed to the multiplex sublayer for the SCH whenthe connected multiplex option is 0xf20.

[0295] Received frames

[0296] The multiplex sublayer in the receiving station categorizes everyreceived MuxPDU(s) in the fundicated and supplemental frame (see [3]),and supplies the MuxPDU type and accompanying bits, if any, to the TDSO.The MusPDU types that are supplied are indicated in Table 10 and Table12 for primary and secondary traffic operations, respectively.

[0297] Interface to Layer 3 Signaling when testing 5 ms FCH/DCCH frames

[0298] When testing 5 ms FCH/DCCH frames, TDSO generates requests toLayer 3 Signaling to send mini messages as opposed to sending TDSOframes as described in the 20 ms frame length case. The same frameactivity model will be used for each 5 ms frame to determine whether torequest Layer 3 Signaling to send a mini message or not during thatframe. Since TDSO has no control of timing in Layer 3 Signaling, themini message may actually be transmitted at a later 5 ms frame.

[0299] To test the Forward 5 ms FCH/DCCH frames, the TDSO in the basestation shall request Layer 3 Signaling to transmit Forward SupplementalChannel Assignment Mini Message (FSCAMM), according to the frameactivity. The base station shall fill the FSCAMM in accordance with 0.The base station should count the number of 5 ms frames transmitted,which includes all the transmitted and retransmitted 5 ms Layer 3Signaling messages. The mobile station keeps a reception counter (see[3]) of the number of good 5 ms frames received (e.g., MUX1_FOR_FCH_5_mswhen Multiplex Option 0x01 is used on a Forward Fundamental Channel).

[0300] To test the Reverse 5 ms FCH/DCCH frames, the TDSO in the mobilestation shall request Layer 3 Signaling to transmit Supplemental ChannelRequest Mini Messages (SCRMM), according to the frame activity. Themobile station shall fill the SCRMM_REQBLOB in the SCRMM in accordancewith 0. The base station should count the number of good 5 ms framesreceived, which includes all the good transmitted and retransmitted 5 msLayer 3 Signaling messages. The mobile station keeps a transmissioncounter (see [3]) of the number of 5 ms frames transmitted (e.g.,MUX1_REV_FCH_5_ms when Multiplex Option 0x01 is used on a ReverseFundamental Channel).

[0301] No text.

TDSO Procedures and Description

[0302] Negotiation and activation of service option

[0303] The mobile stations and base stations that conform to cdma2000are required to support service configuration and negotiation asdescribed in [5].

[0304] Mobile station requirements

[0305] The TDSO shall be negotiated and connected using the serviceconfiguration and negotiation procedures defined in [5]. For the TDSO,the mobile station shall not propose a service configuration whoseattributes are inconsistent with the valid service configurationattribute for the service option. For a mobile station operating inMC-41 mode, the mobile station shall indicate the preferred Forward RCand Reverse RC in the FOR_RC_PREF field and the

[0306] REV_RC_PREF field, respectively, in the Page Response Message andOrigination Message. For a mobile station operating in MC-MAP mode (see[6]), the mobile station shall indicate the preferred Forward RC andReverse RC in the FOR_RC_PREF field and the REV_RC_PREF field,respectively, in the MC-MAP RRC Connection Request Message. Whenproposing the TDSO, the mobile station shall not accept a serviceconfiguration whose attributes are inconsistent with the valid serviceconfiguration attributes for the service option as listed in Table 14.The default service configuration for the TDSO shall be as shown in thevalid service configuration detailed in Table 14. TABLE 14 Valid serviceconfiguration attributes for test data service option Serviceconfiguration attribute Valid selections¹ Forward Multiplex Option 0 ×01² or 0 × 02³ Reverse Multiplex Option 0 × 01⁴ or 0 × 02⁵ ForwardTransmission Rates For the FCH, Rates 1, 1/2, 1/4, and 1/8 enabled. Forthe DCCH, Rate 1 enabled, Rates 1/2, 1/4, and 1/8 not enabled. ReverseTransmission Rates For the FCH, Rates 1, 1/2, 1/4, and 1/8 enabled. Forthe DCCH, Rate 1 enabled, Rates 1/2, 1/4, and 1/8 not enabled. ForwardTraffic Type Primary⁶ or Secondary Traffic Reverse Traffic Type Shouldbe identical to the Forward Traffic Type Forward FCH Radio ConfigurationRC 1, 2, 3, 4, 5, 6, 7, 8, or 9 Reverse FCH Radio Configuration RC 1, 2,3, 4, 5, or 6 Forward DCCH Radio Configuration RC 3, 4, 5, 6, 7, 8, or 9Reverse DCCH Radio Configuration RC 3, 4, 5, or 6 Forward SCH RadioConfiguration RC 3, 4, 5, 6, 7, 8, or 9 Reverse SCH Radio ConfigurationRC 3, 4, 5 or 6 Forward SCH Frame Size 20 ms, 40 ms, or 80 ms ReverseSCH Frame Size 20 ms, 40 ms, or 80 ms Forward Supplemental Channel 0 ×921, 0 × 911, 0 × 909, 0 × 905, 0 × 821, Multiplex Option 0 × 811, 0 ×809, 0 × 03 0 × 922, 0 × 912, 0 × 90a, 0 × 906, 0 × 822, 0 × 812, 0 ×80a, 0 × 04 0 × f20 Reverse Supplemental Channel 0 × 921, 0 × 911, 0 ×909, 0 × 905, 0 × 821, Multiplex Option 0 × 811, 0 × 809, 0 × 03 0 ×922, 0 × 912, 0 × 90a, 0 × 906, 0 × 822, 0 × 812, 0 × 80a, 0 × 04 0 ×f20

[0307] If the mobile station originates or accepts a TDSO call, then themobile station shall perform the following:

[0308] If the TDSO call is mobile station terminated, then the mobilestation shall initiate an auto-answer before entering the Waiting forMobile Station Answer subsate.³

[0309] The mobile station shall connect the TDSO at the action timespecified in the Service Connect Message, the General Handoff DirectionMessage, or the Universal Handoff Direction Message containing the TDSOservice option connection, and shall initialize the service option asspecified in Section Oin this document. While the service option isconnected, the TDSO shall process the received frames as specified inOand generate and supply frames for transmission as specified in 0.

[0310] Supplemental channel allocation

[0311] The mobile station may request high-speed operation on theSupplemental Channel(s) by sending one of the following messages to theBSC/MSC at an implementation-defined time:

[0312] Supplemental Channel Request Message (SCRM)

[0313] Supplemental Channel Request Mini Message (SCRMM)

[0314] If a Supplemental Channel Request Message is used, the mobilestation shall:

[0315] Assemble the SCRM_REQ_BLOB (see Table 15)

[0316] Set the DURATION field in the SCRM_REQ_BLOB to ′1111′

[0317] Include the SCRM_REQ_BLOB in the REQ_BLOB field in theSupplemental Channel Request Message

[0318] Set the SIZE_OF_REQ_BLOB field in the Supplemental ChannelRequest Message to the number of octets in the SCRM_REQ_BLOB

[0319] If a Supplemental Channel Request Mini Message is used, themobile station shall:

[0320] Assemble the SCRMM_REQ_BLOB (see Table 16) and include it in theREQ_BLOB field in the Supplemental Channel Request Mini Message

[0321] Set the DURATION field in the SCRMM_REQ_BLOB to ′1111′

[0322] Include the SCRMM_REQ_BLOB in the REQ_BLOB field in theSupplemental Channel Request Mini Message

[0323] After the mobile station sends the Supplemental Channel RequestMessage or Supplemental Channel Request Mini Message, the BS may respondwith an allocation message (ESCAM, RSCAMM, or UHDM). The mobile stationshall not repeat the request sooner than one second after the requestwas sent. If the mobile station receives an UHDM, ESCAM, FSCAMM, orRSCAMM that changes the transmission rates available to the mobilestation on the Supplemental Channel, the mobile station shall:

[0324] At the start time indicated by the FOR_SCH_START_TIME orREV_SCH_START_TIME fields, reinitialize the TDSO to supply one or moredata blocks at the new rate, filled with all 1 bits with a 100% frameactivity (that is, continuously) to the multiplex sublayer for theSCH(s) until the next synchronization frame (see Ofor description ofsynchronization frame).

[0325] At the synchronization frame time, the TDSO shall:

[0326] Reset all counters associated with the involved SupplementalChannels.

[0327] Commence using the same test parameters for the channel that wasused before the rate change took effect.

[0328] If the mobile station receives a UHDM, a ESCAM, a RSCAMM, or aFSCAMM that deallocates the current Supplemental Channel(s):

[0329] The mobile station shall continue transmitting the TDSO trafficover the Fundicated Channels without any reinitialization.

[0330] The mobile station may request high-speed operation on theSupplemental Channel(s) by sending a Supplemental Channel RequestMessage or, if permitted by the base station, a Supplemental ChannelRequest Mini Message to the BSC/MSC at an implementation-defined time.TABLE 15 SCRM_REQ_BLOB format Length Field (bits) DefinitionDURATION_UNIT 3 The mobile station shall set this field to one less thanthe number of 20 ms intervals in a single duration period. NUM_REQ 3 Themobile station shall set this field to the number of service requestrecords in the SCRM_REQ_BLOB. RESERVED 2 The mobile station shall setthis field to ‘00’. Followed by NUM REQ occurrences of the followingservice request record: SR_ID 3 The mobile station shall set this fieldto the service reference identifier associated with the service option.PREFERRED_RATE 4 The mobile station shall set this field to the ReverseSupplemental Channel Rate (according to Table 17) that it prefers to usefor this reverse high-speed operation for this service option. DURATION9 The mobile station shall set this field to the number of durationperiods that the mobile station requires reverse high-speed operationfor this service option. A value of ‘111111111’ indicates a request foran infinite duration.

[0331] TABLE 16 SCRMM_REQ_BLOB format Length Field (bits) DefinitionSR_ID 3 The mobile station shall set this field to the service referenceidentifier associated with this service option. PREFERRED_RATE 4 Themobile station shall set this field to the Reverse Supplemental ChannelRate (according Table 17) that it prefers to use for this reverse high-speed operation for this service option. DURATION 4 The mobile stationshall set this field to the number of 20 ms intervals (according Table18) that the mobile station requires reverse high-speed operation at thePREFERRED_RATE for this service option. RESERVED 5 The mobile stationshall set this field to ‘00000’.

[0332] TABLE 17 Encoding of the PREFERRED_RATE field Requested reverseRequested reverse PREFERRED_RATE supplemental channel supplementalchannel field rate (kbps) for RC rate (kbps) for RC using value (binary)using N × 9.6 N × 14.4 ‘0000’ 9.6 14.4 ‘0001’ 19.2 28.8 ‘0010’ 38.4 57.6‘0011’ 76.8 115.2 ‘0100’ 153.6 230.4 ‘0101’ 307.2 460.8 ‘0110’ Reserved518.4 ‘0111’ 614.4 1036.8 ‘1000’-‘1111’ Reserved Reserved

[0333] TABLE 18 Encoding of the DURATION field DURATION field value(binary) Number of 20 ms intervals ‘1111’ Infinite

[0334] CDMA-CDMA hard handoff scenario

[0335] While in a TDSO call, if the mobile station receives a UniversalHandoff Direction Message signaling a hard handoff in which the activeset, frame offset, or frequency assignment changes, upon performing thehard handoff, the mobile station shall:

[0336] At the action time associated with the message, reinitialize theTDSO to supply data blocks with all 1 bits at a 100% frame activity tothe multiplex sublayer for the FCH/DCCH channels (depending on thechannel configuration).

[0337] If a supplemental channel assignment is included, at the starttime indicated by the FOR_SCH_START_TIME or REV_SCH_START_TIME fields,reinitialize the TDSO to supply one or more data blocks at the new ratefilled with all 1 bits with a 100% frame activity to the multiplexsublayer for the SCH(s).

[0338] If the TDSO call in progress is a mobile-originated call, afterthe hard handoff, the mobile station shall propose the test parametersthat were in effect before the hard handoff to the base station in acontrol directive using the Service Option Control Message.

[0339] Base station requirements

[0340] The TDSO shall be negotiated and connected using the serviceconfiguration and negotiation procedures defined in [5]. For the TDSO,the base station shall not propose a service configuration whoseattributes are inconsistent with the valid service configurationattribute for the service option. The base station shall not accept aservice configuration whose attributes are inconsistent with the validservice configuration attributes for the service option as shown inTable 14 . The base station should not propose a reverse RC that isdifferent than the one proposed by the mobile station.

[0341] The BS controls both the forward and reverse high-speed operationby allocating Supplemental Channels for an infinite duration. Allocationis specified in the ESCAM, FSCAMM, RSCAMM, or UHDM.

[0342] Synchronization frame

[0343] The Forward and Reverse Traffic Channels (F/R-FCH or F/R-DCCH,F/R-SCH0 and F/R-SCH1) are each subdivided into independent segments of10.24 seconds each. This corresponds to every:

[0344] 2048 frames for physical channels (FCH, DCCH) with 5 ms framelength

[0345] 512 frames for physical channels (FCH, DCCH or SCH) with 20 msframe length

[0346] 256 frames for Supplemental Channels with a 40 ms frame length

[0347] 128 frames for a Supplemental Channel with an 80 ms frame length

[0348] The first frame of a segment is called the synchronization frame.All pseudo-random number generators associated with the channel arereinitialized prior to TDSO frame processing for each synchronizationframe. All service option initialization and control operations alsotake effect prior to TDSO frame processing for a synchronization framefor each physical channel.

[0349] Forward Traffic Channels

[0350] For the Forward Traffic Channels (F-FCH, F-DCCH, F-SCH0, andF-SCH1), the synchronization frames shall be those frames for which theleast significant nine bits of the System Time in frames (as defined in[2]) are equal to the least significant nine bits of the bit-wiseexclusive-OR of the least significant 32-bits Public Long Code Mask(PLCM_32) of the mobile station and the value 0x2aaaaaaa.

[0351] Forward Supplemental Channels

[0352] For 40 ms and 80 ms frame length operation on the ForwardSupplemental Channels, however, the synchronization frame time ascalculated for the Forward Traffic Channels above may not coincide withthe beginning of the frame period for these channels. In that case, thecircular buffer shall still be generated using the same generator as forother forward channels (F-FCH/DCCH) for the 20 ms frame length. However,the beginning of the next frame period on the Forward SupplementalChannel that is closest in time to the frame as calculated above forForward Traffic Channels shall be treated as the first frame of the next10.24-second test segment for the Forward Supplemental Channel.

[0353] Reverse Traffic Channels

[0354] For the Reverse Traffic Channels (R-FCH, R-DCCH, R-SCH0, andR-SCH1), the synchronization frames shall be those frames for which theleast significant nine bits of the System Time in frames (as defined in[2]) are equal to the least significant nine bits of the bit-wiseexclusive-OR of the least significant 32-bits Public Long Code Mask(PLCM_32) of the mobile station and the value 0x15555555.

[0355] Reverse Supplemental Channels

[0356] For 40 ms and 80 ms frame length operation on the ReverseSupplemental Channels, however, the synchronization frame time ascalculated for the Reverse Traffic Channels above may not coincide withthe beginning of the frame period for these channels. In that case, thecircular buffer shall still be generated using the same generator as forother reverse channels (R-FCH/DCCH) for the 20 ms frame length. However,the beginning of the next frame period on the Reverse SupplementalChannel closest in time to the frame as calculated above for ReverseTraffic Channels shall be treated as the first frame of the next10.24-second test segment for the Reverse Supplemental Channel.

[0357] Counters

[0358] The mobile station and the base station shall support thetransmit counters listed in Table 19 and Table 20 for the Fundicated andSupplemental Channels, respectively. TABLE 19 Transmit frame counters onthe fundicated channel Generated frame type Transmitted frame typeCounter name Rate 1 Rate 1 with no signaling TDSO_E1_T1 Rate 1 Rate 1with dim-and-burst signaling TDSO_E1_TD Rate 1 Rate 1 withblank-and-burst signaling TDSO_E1_TB Blank Blank TDSO_EB_TB BlankAnything other than blank TDSO_EB_TO

[0359] TABLE 20 Transmitted frame counters on the Supplemental ChannelSCH-generated frame Transmitted frame type type (kbps) (kbps) Countername N × 9.6 or N × 14.4¹ N × 9.6 or N × 14.4 TDSO_ENx_TNx N × 9.6 or N× 14.4¹ Blank TDSO_ENx_TB Blank Blank TDSO_EB_TB

[0360] The mobile station and the base station shall support the receivecounters listed in Table 21 and Table 22. TABLE 21 Receive framecounters maintained for the FCH/DCCH Expected frame type Received frametype Counter name Rate 1 Error-free Rate 1 frame with no dim- TDSO_E1_R1and-burst Rate 1 Rate 1 with bit errors detected by the TDSO_E1_RERRservice option Rate 1 Dim-and-burst frame TDSO_E1_RD Rate 1 Other rateframe TDSO_E1_RO Rate 1 Blank-and-burst TDSO_E1_RB Rate 1 Rate 1physical layer frame with TDSO_E1_RFL insufficient physical layer framequality¹ Rate 1 Insufficient frame quality (erasure) TDSO_El_RE NullNull TDSO_EN_RN Null Blank TDSO_EN_RB Null Other TDSO_EN_RO

[0361] TABLE 22 Receive frame counters on the Supplemental Channel SCHexpected frame type Received frame type Counter name N × 9.6 or N × 14.4Error-free N × 9.6 or TDSO_ENx_RNx N × 14.4 frame N × 9.6 or N × 14.4 N× 9.6 or N × 14.4 TDSO_ENx_RERR frame with bit errors detected by theservice option N × 9.6 or N × 14.4 Insufficient frame qualityTDSO_ENx_RE (erasure) N × 9.6 or N × 14.4 Blank TDSO_ENx_RB Blank BlankTDSO_EB_RB Blank Anything other than TDSO_EB_RO blank

[0362] The mobile station shall support the counters in Table 23 for thecalculation of PER on the Supplemental Channels. TABLE 23 Receive PDUcounters maintained for the Supplemental Channels SCH expected Bitcounter rate Received MuxPDU type name 3 Error-free Rate 3 MuxPDUTDSO_E3_R3 3 Rate 3 MuxPDU with errors detected TDSO_E3_RERR by the TDSO3 Insufficient frame quality (erasure) TDSO_E3_RE 2 Error-free Rate 2MuxPDU TDSO_E2_R2 2 Rate 2 MuxPDU with errors detected TDSO_E2_RERR bythe TDSO 2 Insufficient frame quality (erasure) TDSO_E2_RE 1a¹Error-free Rate 1a MuxPDU TDSO_E1a_R1a 1a Rate 1a MuxPDU with errorsdetected TDSO_E1a_RERR by the TDSO 1a Insufficient frame quality(erasure) TDSO_E1a_RE 1b² Error-free Rate 1b MuxPDU TDSO_E1b_R1b 1b Rate1b MuxPDU with errors detected TDSO_E1b_RERR by the TDSO 1b Insufficientframe quality (erasure) TDSO_E1b_RE

[0363] The following buffers shall be capable of storing the framecounter values as shown in the following tables. TABLE 24 Framecounter-value storage Channel Buffer Station Counter-value storage type¹R-FCH RFCH_BUFFER Mobile Transmit Base Receive R-DCCH RDCCH_BUFFERMobile Transmit Base Receive F-FCH FFCH_BUFFER Mobile Transmit BaseReceive F-DCCH FDCCH_BUFFER Mobile Transmit Base Receive

[0364] TABLE 25 Frame counter-value storage for Supplemental ChannelsChannel Buffer Station Counter-value storage type* R-SCH0 RSCH0_BUFFERMobile Transmit Base Receive R-SCH1 RSCH1_BUFFER Mobile Transmit BaseReceive F-SCH0 FSCHO_BUFFER Mobile Transmit Base Receive Mobile TransmitBase Receive

[0365] Mobile station initialization and control operation

[0366] Service option initialization

[0367] If a TDSO initialization is required as a result of a signalingmessage on f-dsch, the mobile station shall consider the System Time inframes coinciding with the action time of the message (as defined in[5]) to be the effective initialization frame, EFF_FRAME.

[0368] For the Forward and Reverse Fundicated Traffic Channels (F/R-DCCHand/or F/R-FCH), the TDSO shall consider the System Time in frames thatcoincide with the action time of the Service Connect Message as theinitialization frame. For the Forward and Reverse Supplemental Channels(F/R-SCH0 and/or F/R-SCH1), the TDSO shall consider the System time inframes coinciding with the start time indicated by theFOR_SCH_START_TIME (for Forward Supplemental Channels) orREV_SCH_START_TIME (for Reverse Supplemental Channels) fields inside ofthe ESCAM, FSCAMM, RSCAMM, or UHDM that is the initialization frame.

[0369] The initialization frame may coincide with the synchronizationframe on a physical channel. Until the first synchronization on achannel is achieved, the TDSO shall only use the default settings forthe test parameters, that is, an all 1's data pattern with a continuoustransmission every frame period (20 ms, 40 ms, or 80 ms) on thatchannel.

[0370] To perform TDSO initialization, the mobile station shall performthe following operations:

[0371] Immediately prior to TDSO frame processing for the ReverseTraffic Channel (that is, R-FCH/R-DCCH/R-SCH0/R-SCH1) synchronizationframe for which the System Time in frames falls in the range fromEFF_FRAME to EFF_FRAME+FRAMES_PER SEGMENT_1 inclusive, the mobilestation shall set the counters associated with the Reverse TrafficChannels to zero.

[0372] For Reverse Fundicated Traffic Channels, the counters areRFCH_BUFFER and RDCCH_BUFFER

[0373] For Reverse Supplemental Channels, the counters areRSCHO_BUFFERand RSCH1_BUFFER

[0374] The value of FRAMES_PER_SEGMENT_1 shall be:

[0375] 511 for a 20 ms physical channel frame length

[0376] 255 for a 40 ms physical channel frame length

[0377] 127 for a 80 ms physical channel frame length

[0378] Immediately prior to TDSO frame processing for the ForwardTraffic Channel (that is, F-FCH/F-DCCH/F-SCH0/F-SCH1) synchronizationframe for which the System Time in frames falls in the range fromEFF_FRAME to EFF_FRAME+FRAMES_PER_SEGMENT_1 inclusive, the mobilestation shall set the counters associated with the Forward TrafficChannels to zero.

[0379] For Forward Fundicated Traffic Channels, the counters areFFCH_BUFFER and FDCCH_BUFFER

[0380] For Forward Supplemental Channels, the counters are FSCHO_BUFFERand FSCH1_BUFFER

[0381] The value of FRAMES_PER_SEGMENT_1 shall be:

[0382] 511 for a 20 ms physical channel frame length

[0383] 255 for a 40 ms physical channel frame length

[0384] 127 for a 80 ms physical channel frame length

[0385] Mobile station control operations

[0386] Control invocation

[0387] The mobile station can either propose or invokeservice-option-specific functions for a TDSO call by sending a ServiceOption Control Message to the base station. When the mobile stationsends the Service Option Control Message, it shall:

[0388] Send it as a message requiring acknowledgment

[0389] Set the CONTROL_CODE field in the message (see Table 39) to′00000000′ The mobile station can only propose values of test parametersfor use during the test interval. The mobile shall be able to invoke thecounter retrieval directives without any base station mediation.

[0390] Control directive

[0391] When the mobile station receives a Service Option Control Messagewith CTL_REC_TYPE in the range ′0000001′- ′00000100′ inclusive(corresponding to FCH, DCCH, SCH0, or SCH1 physical channels) asindicated in Table 39, the mobile station shall consider the System Timein frames coinciding with the action time of the message to be theeffective operation frame or initialization frame (also known asEFF_FRAME for the particular physical channel).

[0392] Reverse Traffic Channel

[0393] Immediately prior to TDSO frame processing for the ReverseTraffic Channel synchronization frame for which the System Time inframes falls in the range from EFF_FRAME to EFF_FRAME+511, inclusive,the mobile station shall perform the following:

[0394] If the COPY_COUNTERS field is equal to ′1′, the mobile stationshall copy the counters associated with the specified Reverse TrafficChannel to RFCH_BUFFER, RDCCH_BUFFER, RSCHO_BUFFER, and/or RSCH1_BUFFERas determined by the channel configuration (see Section 3.3 for moreinformation).

[0395] If the CLEAR COUNTERS field is equal to ′1′, the mobile stationshall set the counters associated with the specified Reverse TrafficChannel to zero (see Section 3.3 for more information).

[0396] If the CHANNEL_DIRECTION field is equal to ′00′ or ′10′, themobile station shall perform the following:

[0397] Initialize the local test variables associated with DATA_SOURCEto the value implied by its value in the message.

[0398] Initialize the local test variables associated withFRAME_ACTIVITY to the value implied by its value in the message.

[0399] Forward Traffic Channel

[0400] Immediately prior to TDSO frame processing for the ForwardTraffic Channel synchronization frame for which the System Time inframes falls in the range from EFF_FRAME to EFF_FRAME+511, inclusive,the mobile station shall do the following:

[0401] If the COPY_COUNTERS field is equal to ′1′, the mobile stationshall copy the counters associated with the specified Forward TrafficChannel to FFCH_BUFFER, FDCCH_BUFFER, and/or FSCH_BUFFER (see Section3.3 for more information).

[0402] If the CLEAR_COUNTERS field is equal to ′1′, the mobile stationshall set the counters associated with the specified Forward TrafficChannel to zero (see Section 3.3 for more information).

[0403] If the CHANNEL_DIRECTION field is equal to ′00′ or ′01′, themobile station shall perform the following:

[0404] Initialize the local test variables associated with DATA_SOURCEto the value implied by its value in the message.

[0405] Initialize the local test variables associated withFRAME_ACTIVITY to the value implied by its value in the message.

[0406] Following a mobile station test control proposal (see Section3.5.1 for a description), if a mobile station receives a Service OptionControl Message with CTL_REC_TYPE in the range ′00000001′-′00000100′inclusive (corresponding to FCH, DCCH, SCH0, or SCH1 physical channels)as listed in Table 38, the mobile station shall perform the following:

[0407] If the CONTROL_CODE field is set to ′00000011′, the mobilestation may send another proposal with the NUM_CIRC_BUF_FRAMES field setto a value less than or equal to the value indicated in thecorresponding field of the base station directive.

[0408] If the CONTROL_CODE field is set to ′00000110′, the mobilestation may send another proposal with the FRAME_SOURCE field set to avalue other than 10.

[0409] Counter retrieval

[0410] When the mobile station receives a Service Option Control Messagewith CTL_REC_TYPE in the range of ′00000101′-′0000l000′ (correspondingto FCH, DCCH, SCH0, or SCH1 physical channels) as listed in Table 38,then:

[0411] If the message is used to retrieve the 5 ms Transmitted FrameCounters or the 5 ms Received Frame Counters, then at the firstsynchronization frame boundary, the mobile station shall respond withthe Service Option Control Message containing its response shown inTable 46, corresponding to the VECT_COUNTER_ID fields (see Table 47) inthe received Service Option Control Message.

[0412] Otherwise, at the action time associated with the message, themobile station shall respond with the Service Option Control Messagecontaining its response shown in Table 46 and

[0413] Table 48, respectively, for the Fundicated and SupplementalChannels, corresponding to the VECT_COUNTER_ID fields (see Table 47 andTable 49) in the received Service Option Control Message.

[0414] Base station initialization and control operations

[0415] To perform TDSO initialization, if the FCH/DCCH are configured touse 5 ms frames, the base station shall send a Service Option ControlMessage no later than 1 second before the occurence of the firstsynchronization frame after EFF_FRAME, in accordance with 0, to retrievethe values of the 5 ms frame counters in the mobile station (e.g.,MUX1_FOR_FCH_5_ms). Base station control operations

[0416] Control invocation

[0417] The base station shall use the Service Option Control Message forinvoking service option specific directives. When the base station sendsthe Service Option Control Message, it shall send it as a messagerequiring acknowledgment. When the mobile station proposes values oftest parameters for use during the test interval, the base station shalldecide whether or not to invoke the mobile-station-proposed testparameter settings through the Service Option Control Message.

[0418] The base station shall not send a control directive to the mobilestation any later than one second before the occurrence of thesynchronization frame on the channel for which the directive isintended.

[0419] Control directive

[0420] When the base station receives a Service Option Control Messagewith CTL_REC_TYPE in the range of ′00000001′-′00000100′ inclusive(corresponding to FCH, DCCH, SCH0, or SCH1 physical channels) asindicated in Table 38, the base station shall respond to the mobilestation proposal as follows:

[0421] If all of the fields in the mobile-station-proposed controldirective (as indicated in Table 39) are within the acceptable range forthe base station, the base station shall issue a Control Directiveincluding the same values for the different fields (see Table 39) asproposed by the mobile station in a Service Option Control Message,while setting the CONTROL_CODE field (Table 40) in the message to avalue of ′00000010′.

[0422] If the base station does not have the capability of supportingthe value proposed by the mobile station for the NUM_CIRC_BUF_FRAMES, itshall issue a Control Directive including the same values for thedifferent fields (see Table 39) as were proposed by the mobile station,except for the NUM_CIRC_BUF_FRAMES field in a Service Option ControlMessage, while setting the CONTROL_CODE field (Table 40) in the messageto a value of ′00000011′. In the NUM_CIRC_BUF_FRAMES field of themessage, the base station shall indicate the maximum number of frames itcan support for the circular buffer.

[0423] If the base station does not have the capability of generatingone frame per frame period as requested by the mobile station throughsetting a value of ′10′ for the FRAME_SOURCE field, it shall issue aControl Directive, including the same values for the different fields(see Table 39), as proposed by the mobile station, except for theFRAME_SOURCE field in a Service Option Control Message, while settingthe CONTROL_CODE field (Table 40) in the message to a value of′00000110′.

[0424] If the base station is not able to recognize the fields in themobile-proposed Control Directive, it shall issue a Control Directiveincluding the same values for the different fields (see Table 39), asproposed by the mobile station in a Service Option Control Message,while setting the CONTROL_CODE field (Table 40) in the message to avalue of ′00000101′.

[0425] Counter retrieval

[0426] When the base station receives a Service Option Control Messagewith CTL_REC_TYPE in the range of ′00000101′- ′00001000′ inclusive(corresponding to FCH, DCCH, SCH0, or SCH1 physical channels) as listedin Table 38, then at the action time associated with the message, thebase station shall respond with the Service Option Control Messagecontaining its response, as shown in Table 46 and Table 48,respectively, for the Fundicated and Supplemental Channels,corresponding to the VECT_COUNTER_ID fields (see Table 47 and Table 49)in the received Service Option Control Message.

[0427] TDSO Frame processing

[0428] For an FCH/DCCH that is configured to use 5 ms frames, theservice option shall perform transmit frame processing for 5 ms DCCHframes exactly once for every 5 ms frame of System Time while theservice option is connected on the allocated FCH/DCCH in accordance with0.

[0429] If 20 ms frames are used, the service option shall performtransmit and receive frame processing exactly once for every 20 ms frameof System Time while the service option is connected on the allocatedphysical channel(s) in accordance with 0 and 0, respectively.

[0430] If 40 ms (or 80 ms) SCH frames are used, the service option shallperform transmit and receive frame processing exactly once for every 40ms (or 80 ms) frame of System Time while the service option is connectedon the allocated SCH in accordance with 0 and 0, respectively.

[0431] Transmit frame processing

[0432] Transmit frame processing refers to F-FCH/F-DCCH/F-SCH ForwardTraffic Channel frame processing in the base station orR-FCH/R-DCCH/R-SCH Reverse Traffic Channel frame processing in themobile station. Transmit frame processing consists of the following:

[0433] Generating data block(s)

[0434] Supplying data block(s) to the multiplex sublayer fortransmission

[0435] Incrementing the corresponding counters

[0436] The service option shall generate the data blocks in accordancewith 3.7. For Fundicated data frames (carried over FCH or DCCH), if themultiplex sublayer has requested a Blank data block, the service optionshall supply a blank data block (data block containing no bits) to themultiplex sublayer. If the multiplex sublayer has requested a non-blankx-bit data block, the service option shall supply the first x bits ofthe generated data block to the multiplex sublayer and discard the restof the generated data block. Otherwise, the service option shall supplythe generated data block(s) to the multiplex sublayer, every physicalchannel frame.

[0437] For Supplemental data frames, if the multiplex sublayer hasrequested a Blank data block or Blank data blocks, the service optionshall supply a data block or data blocks containing zero bits to themultiplex sublayer. Otherwise, the service option shall supply thegenerated data block(s) to the multiplex sublayer every SCH frame.

[0438] The service option shall increment the counters that are shown inTable 26 and Table 27, corresponding to the rate of the generatedFundicated and Supplemental frames and the command received from themultiplex sublayer. TABLE 26 Counters for fundicated transmitted framesRate of generated frame Multiplex sublayer command Counter to increment1 None TDSO_E1_T1 1 MaxRate = Rate 1/2 TDSO_E1_TD 1 Blank TDSO_E1_TBBlank None TDSO_EB_TB Blank Maximum Rate = Rate 1/2 or TDSO_EB_TO Blank

[0439] TABLE 27 Counters for supplemental transmitted frames SCH rate ofgenerated Multiplex sublayer frame (kbps) command Counter to increment N× 9.6 or N × 14.4¹ None TDSO_ENx_TNx N × 9.6 or N × 14.4 BlankTDSO_ENx_TB Blank None TDSO_EB_TB

[0440] Receive frame processing

[0441] Receive frame processing refers to F-FCH/F-DCCH/F-SCH frameprocessing in the mobile station or R-FCH/R-DCCH/R-SCH frame processingin the base station. Receive frame processing consists of the following:

[0442] Generating data block(s)

[0443] Accepting data block(s) from the multiplex sublayer

[0444] Comparing the rates and contents of the comparable data block(s)

[0445] Incrementing the corresponding counters

[0446] For Fundicated Channel processing:

[0447] The service option shall generate a data block in accordance with3.7.

[0448] The service option shall accept a received frame and thecategorization of the MuxPDU(s) from the multiplex sublayer.

[0449] If the categorization of the received MuxPDU corresponds to therate of the generated data block, the service option shall compare thecontents of the generated data block with the contents of the receiveddata block, and shall determine whether or not they are identical.

[0450] The service option shall increment the counter shown in Table 28(when MuxPDU Type 1 is used) or

[0451] Table 29 (when MuxPDU Type 2 is used) corresponding to the rateof the generated data block, the categorization of the received MuxPDU,and the result, if any, of the comparison of the data blocks. TABLE 28Counter updates for received fundicated frames when MuxPDU 5 Type 1 isused Category of Category of Data received received block Rate of MuxPDUfor MuxPDU for com- generated primary secondary parison Counter to frametraffic traffic identical increment 1  1 14 Y TDSO_E1_R1 1  1 14 NTDSO_E1_RERR 1 2, 3, 4, 11, 11, 12, 13 N/A TDSO_E1_RD 12, 13 1 6, 7, 8N/A N/A TDSO_E1_RO 1 5, 14 1-8 N/A TDSO_E1_RB 1  9  9 N/A TDSO_E1_RFL 110 10 N/A TDSO_E1_RE Blank 15 15 N/A TDSO_EN_RN Blank 5, 14 1-8 N/ATDSO_EN_RB Blank 1-4, 6-13  9-14 N/A TDSO_EN_RO

[0452] TABLE 29 Counter updates for received fundicated frames whenMuxPDU Type 2 is used Catergory of Category of Rate received received ofgen- MuxPDU for MuxPDU for Data block erated primary secondarycomparison Counter to frame traffic traffic identical? increment 1 1 9 YTDSO_(—) E1_R1 1 1 9 N TDSO_(—) E1_RERR 1 2-4, 6-8, 10, 6-8, 10, 15, 16,N/A TDSO_(—) 12, 13, 15, 16, 18, 22 E1_RD 18, 20, 22 1 5, 9, 14, 17,1-5, 11-14, N/A TDSO_(—) 21, 23, 25 19-21, 24 E1_RB 1 26 26 N/A TDSO_(—)E1_RE 1 11, 19, 24 17, 23, 25 N/A TDSO_(—) E1_RO Blank 27 27 N/ATDSO_(—) EN_RN Blank 5, 9, 14, 17, 1-5, 11-14, N/A TDSO_(—) 21, 23, 2519-21, 24 EN_RB Blank 1-4, 6-8, 6-10, 15-18, N/A TDSO_(—) 10-13, 15, 16,22, 23, 25, 26 EN_RO 18-20, 22, 24, 26

[0453] For Supplemental Channel processing:

[0454] The service option shall generate one ore more data blocks inaccordance with 3.7 for every SCH frame.

[0455] The service option shall accept one or more data blocks, alongwith a categorization of each MuxPDU (see [3]), from the multiplexsublayer at every frame, as dictated by the connected multiplex option.

[0456] If the categorization of the received MuxPDU(s) corresponds tothe rate of the corresponding generated frame, the service option shallcompare the contents of the generated data block(s) with the contents ofthe received data block(s), and shall determine whether or not they areidentical.

[0457] The service option shall increment the counter shown in Table 30corresponding to the rate of the generated frame, the categorization ofthe received MuxPDU(s), and the result, if any, of the comparison of thetwo frames. These counters are employed in PER calculations on theSupplemental Channels.

[0458] If all of the data block(s) received within a frame interval areidentical to the locally generated data block(s), the frame is declarederror-free and the corresponding frame counter is incremented to reflectthis as shown in Table 31. Otherwise, the frame error is noted in theappropriate counter. These counters are employed in FER calculations onthe Supplemental Channels. TABLE 30 Counter updates for PDUs received onSupplemental Channels Rate of generated Category of Data block dataCategory received comparison Counter to block expected MuxPDU identical?increment 3 2 2 Y TDSO_E3_R3 3 2 2 N TDSO_E3_RERR 3 2 1 N/A TDSO_E3_RE 25 5 Y TDSO_E2_R2 2 5 5 N TDSO_E2_RERR 2 5 3 N/A TDSO_E2_RE 1a 1(2)¹ 1(2)Y TDSO_E1a_R1a 1a 1(2) 1(2) N TDSO_E1a_RERR 1a 1(2) 3 N/A TDSO_E1a_RE 1b4 4 Y TDSO_E1b_R1b 1b 4 4 N TDSO_E1b_RERR 1b 4 3 N/A TDSO_E1b_RE

[0459] TABLE 31 Counter updates for received frames on SupplementalChannels Category of each Category of each received MuxPDU receivedMuxPDU (if carried as (if carried as secondary traffic) primary traffic)frame Rate of MuxPDU Type MuxPDU Type Frame Counter generated in use inuse comparison to frame 1 2 3 5 1 2 3 5 identical? increment N × 9.6 or1 1 4,5 2 2 2 4,5 2 Y TDSO_EN N × 14.4¹ x_RNX N × 9.6 or 1 1 4,5 2 2 24,5 2 N TDSO_EN N × 14.4 x_RERR N × 9.6 or 3 3 3 1 3 3 3 1 N/A TDSO_EN N× 14.4 x_RE N × 9.6 or 2 2 4,5 2 1 1 4,5 2 N/A TDSO_EN N × 14.4 x_RBBlank 2 2 4,5 2 1 1 4,5 2 N/A TDSO_EB_RB Blank 1,3 1,3 3 1 2,3 2,3 3 1N/A TDSO_EB_RO

[0460] Transmit frame processing for 5 ms FCH/DCCH frames

[0461] Mobile Station Requirement

[0462] For R-FCH/DCCH 5 ms transmit frame processing in the mobilestation, the 5 TDSO shall request Layer 3 Signaling to transmit a SCRMMwhen TDSO decides to send a 5 ms frame based on the frame activity. Ifthe R-SCH0 has already been assigned, the mobile station shall set thefields of the SCRMM_REQ_BLOB as follows:

[0463] SR_ID set to the sr_id corresponding to the connected SO

[0464] PREFERRED_RATE set to the currently connected R-SCHO rate

[0465] DURATION field set to ′1111′

[0466] Otherwise, the mobile station should set the fields of theSCRMM_REQ_BLOB as follows:

[0467] SR_ID set to the sr_id corresponding to the connected SO

[0468] PREFERRED_RATE set to any valid R-SCHO rate

[0469] DURATION field set to ′0000′

[0470] The mobile station counts and stores the number of transmitted orretransmitted 5 ms frames in the counters (MUX1_REV_FCH_5_ms,MUX2_REV_DCCH_5_ms, MUX2_REV_DCCH_5_ms and MUX2_REV_FCH 5 ms) asspecified in [3].

[0471] Since TDSO has no control on timing in Layer 3 Signaling, theactual transmission of the mini message may occur in a later frame.

[0472] Base Station Requirement

[0473] For F-FCH/DCCH 5 ms transmit frame processing in the basestation, the TDSO shall request Layer 3 Signaling to transmit an FSCAMMwhen TDSO decides to send a 5 ms frame based on the frame activity. Ifthe F-SCH0 has already been assigned, the base station should set thefields of the FSCAMM as follows:

[0474] FOR_SCH_ID set to ′0′

[0475] FOR_SCH_DURATION field set to ′1111′

[0476] SCCL_INDEX set to the Supplemental Channel Code list indexcorresponds to one currently in use by F-SCH0.

[0477] Otherwise, the base station should set the fields of the FSCAMMas follows:

[0478] FOR_SCH_ID set to ′0′

[0479] FOR_SCH_DURATION field set to ′0000′

[0480] SCCL_INDEX set to any Supplemental Channel Code list index thatcorresponds to F-SCH0, if available. If there is no Supplemental ChannelCode list index corresponds to F-SCHO, SCCL_INDEX shall be set to anyvalue, in which case the mobile station ignores the SCCL_INDEX field.

[0481] The base station should count the number of transmitted orretransmitted 5 ms frames, which includes the following:

[0482] Any 5 ms frame carrying a mini message that is initiated by TDSO

[0483] Any 5 ms frame carrying a mini message that is not initiated byTDSO

[0484] A retransmitted 5 ms frame due to LAC retransmission

[0485] TDSO frame generation

[0486] Two different categories of traffic can be transported over theconnected TDSO:

[0487] Selectable byte pattern

[0488] Pseudo-randomly generated bits

[0489] At the physical layer, by default, the TDSO is configured togenerate primary traffic over the Forward and Reverse FundamentalChannels using RC3. The default test mode for the TDSO service option isthe byte pattern 0xFF with a 100% frame activity.

[0490] For every 20 ms FCH/DCCH frame, when TDSO generates a TDSO frame,it shall generate a Rate 1 data block.For every SCH frame, when TDSOgenerates a TDSO frame, it shall generate one or more Rate 1, Rate 2, orRate 3 data blocks that are applicable to the connected SCH rate.

[0491] The actual size of the transmitted data block(s) during a TDSOframe depends on the multiplex sublayer command.

[0492] Selectable byte pattern

[0493] When using this scheme, a single-byte pattern is used to fill thedata block or data blocks that are passed to the multiplex sublayer (upto a whole number of octets) during each TDSO frame interval (20 ms, 40ms, or 80 ms).

[0494] When the TDSO prepares a TDSO frame for a traffic channel, itshall perform the following:

[0495] Fill up a Rate 1, Rate 2, or Rate 3 data block, whichever isapplicable, with single-byte pattern up to a whole number of octets. Padthe data block with ′0′ bits for any remaining bits that are not filled.(e.g., a 171-bit Rate 1 has 21 full octets and 3 additional bits. Theadditional remaining bits are filled by ′0′ bits.)

[0496] Replace the first 5 bits of the data block by the header depictedin Table 36. This helps the TDSO on the receive side to categorize thedata blocks on a per-channel and per-PDU basis.

[0497] Pseudo-random number generation

[0498] Pseudo-random number generators are utilized for framegeneration. These generators are associated with a particular physicalchannel (forward or reverse) and are initialized at each synchronizationframe. The pseudo-random number generators are iterated one or moretimes for every frame. Iterations of the pseudo-random number generatorsare used for information bit generation, enough to fill two maximum ratephysical layer frames (per the configured RC). The bits are stored incircular buffers. The buffers are regenerated with a new seed of theSystem Time frame number associated with a synchronization frame every10.24 seconds.

[0499] For each physical channel, a TDSO uses two independentpseudo-random number generators. One pseudo-random number generator isassociated with the Forward Traffic Channel, while the other isassociated with the Reverse Traffic Channel. These pseudo-random numbergenerators are synchronized with their counterparts at the other end ofthe link, as shown in FIG. 1. At synchronization time, the pseudo-randomnumber generator for the transmit side is used for generating thecircular buffer that serves as the data source for bits packed into datablocks each frame period for the next test segment (10.24 seconds). Thereceive side pseudo-random number generator, by emulating the framegeneration process at the other end of the link, enables the serviceoption to verify if a data block(s) is received error-free.

[0500]FIG. 1. Synchronized operation of pseudo-random number generatedbuffers

[0501] On the transmit side, the bits from the circular buffer for aparticular channel are packed serially into data blocks corresponding tothe available MuxPDUs as determined by the connected multiplex option.The multiplex option indicates the size of the data block or datablock(s), which is equal to the number of bits to be copied from thecircular buffer to the last whole octet to form a data block or datablocks. Any remaining bits up to the data block size are filled with ′0′bits. For every frame, the service option shall copy the data bits fromthe circular buffer, starting at a reference point plus an offset, tofill the data block(s). The reference for the current frame shall becalculated as follows: If the current frame is a synchronization frame,the reference point shall be set to zero; otherwise, the reference pointshall be set to the end of the last byte that was copied into theprevious frame. The offset, O_(n), which is generated every frame, shallbe set to the 6 least significant bits of RNG/128 modulo B(n), whereB(n) is the buffer size and RNG is the random number generatorassociated with the physical channel (see Ofor buffer sizes]. Thisprocess is synchronized with its counterpart on the receive side. Thereceive side emulates the frame generation process at the other end byfollowing the same process of building a frame (which consists of one ormore data blocks) from the circular buffer each time from a differentoffset.

[0502] Depending on the frame activity or theTX_ON_PERIOD/TX_OFF_PERIOD, if the TDSO transmits the TDSO frame duringthe current frame, it shall perform the following:

[0503] Replace the first 5 bits of the generated data block(s) with theheader depicted in Table 36. This helps the TDSO on the receive side tocategorize the data blocks on a per-channel and per-PDU basis.

[0504] The TDSO shall pass the generated data block(s) to the multiplexsublayer. The TDSO shall supply the first x bits of the data block tothe multiplex sublayer if the multiplex sublayer requests an x-bit datablock, where x may be smaller than the number of bits in a Rate 1 datablock.

[0505] Otherwise, the TDSO shall discard the generated data block(s)during this frame. The service option shall store the state of all theForward Traffic Channel pseudo-random number generators, FRNG, and thestate of the Reverse Traffic Channel pseudo-random number generators,RRNG.

[0506] Initialization

[0507] Before frame generation for every Forward Traffic Channelsynchronization frame, the service option shall initialize the ForwardTraffic Channel pseudo-random number generator as follows:

[0508] a=16807

[0509] m=2147483647

[0510] FRNG=System Time in frames of the forward synchronization frame

[0511] FRNG=(FRNG0x2AAAAAAA)& 0x7FFFFFFF

[0512] FRNG=(FRNG * a) mod m

[0513] FRNG=(FRNG * a) mod m

[0514] FRNG=(FRNG * a) mod m

[0515] FRNG=(FRNG * a) mod m

[0516] Before frame generation for every Reverse Traffic Channelsynchronization frame, the service option shall initialize the ReverseTraffic Channel pseudo- random number generator as follows:

[0517] a=16807

[0518] m=2147483647

[0519] RRNG=System Time in frames of the reverse synchronization frame

[0520] RRNG=(RRNG0x55555555) & 0x7FFFFFFF

[0521] RRNG=(RRNG * a) mod m

[0522] RRNG=(RRNG * a) mod m

[0523] RRNG=(RRNG * a) mod m

[0524] RRNG=(RRNG * a) mod m

[0525] Number production

[0526] Whenever a pseudo-random number is required for Forward TrafficChannel frame processing, the service option shall use the current valueof FRNG as the pseudo-random number and then shall update FRNG asfollows:

[0527] a=16807

[0528] m=2147483647

[0529] FRNG=(FRNG * a) mod m

[0530] Whenever a pseudo-random number is required for Reverse TrafficChannel frame processing, the service option shall use the current valueof RRNG as the pseudo-random number and then shall update RRNG asfollows:

[0531] a=16807

[0532] m=2147483647

[0533] RRNG=(RRNG *a) mod m

[0534] 24-bit random number

[0535] The pseudo-random number generators that are used to fill thecircular buffers (see Section 0 for more information) to determine thetransitions between the two TDSO states for calculation of frameactivity (see Section 0 for more information) and to select the 6-bitbyte offset in the circular buffer (see Section 0 for more information)each frame period, all have the following linear congruent relationship:

[0536] x_(n)=a×x_(n)−1 mod m,

[0537] where:

[0538] a=7⁵=16807

[0539] m=2³¹−1=2147483647

[0540] x_(n)−1 and x_(n) are the successive outputs of the generator andare 31-bit integers

[0541] However, because of the better randomness properties of the mostsignificant 24 bits within the 31-bit number and for ease of usage,especially for building circular buffers (31-bit number is notoctet-aligned), only the most significant 24 bits of these numbers areused throughout. That is, 24-bit number=31-bit PN number>>7

[0542] Circular buffer sizes

[0543] The sizes of the required buffers for generation of Fundicatedand Supplemental (for each Supplemental Channel) traffic frames forvarious radio configurations (RCs) on the forward/reverse links areindicated in Table 32, Table 33, and Table 34. For convenience, thebuffer sizes are based on the maximum number of bits passed by themultiplex sublayer to the physical layer each frame period (5 ms, 40 ms,or 80 ms) depending on the radio configuration. TABLE 32 Circular buffersizes needed to generate fundicated channel data frames Default circularCircular Reverse Radio Foward Radio buffer size buffer sizeConfiguration Configuration Maximum 2 frames N frames (RC) (RC)bits/frame (bits) (bits) 1, 3, 5 1, 3, 4, 6 or 7 172 2 × 172 = 344 N ×172 2, 4, 6 2, 5, 8 or 9 267 2 × 267 = 534 N × 267

[0544] TABLE 33 Circular buffer sizes needed to generate reverseSupplemental Channel data frames Default cicular Circular Radio buffersize buffer size configuration Maximum 2 frames N frames (RC) bits/frame(bits) (bits) 3  6,120 2 × 6,120 = 12,240 N × 6,120 4  4,584 2 × 4,584 =9,168 N × 4,584 5 12,264 2 × 12,264 = 24,528 N × 12,264 6 20,712 2 ×20,712 = 41,424 N × 20,712

[0545] TABLE 34 Circular buffer sizes needed to generate forwardSupplemental Channel data frames Default cicular Circular Radio buffersize buffer size configuration Maximum 2 frames N frames (RC) bits/frame(bits) (bits) 3  3,048 2 × 3,048 = 6,096 N × 3,048 4  6,120 2 × 6,120 =12,240 N × 6,120 5  4,584 2 × 4,584 = 9,168 N × 4,584 6  6,120 2 × 6,120= 12,240 N × 6,120 7 12,264 2 × 12,264 = 24,528 N × 12,264 8  9,192 2 ×9,192 = 18,384 N × 9,192 9 20,172 2 × 20,712 = 41,424 N × 20,712

[0546] The pseudo-random number generators used to fill the circularbuffers have the following linear congruent relationship:

[0547] x_(n)=a×x_(n)−1 mod m,

[0548] where:

[0549] a=7⁵=16807

[0550] m=2³¹−1=2147483647

[0551] x_(n)−1 and x_(n) are the successive outputs of the generator andare 31-bit integers

[0552] Information bit generation

[0553] For every Forward or Reverse Traffic Channel frame, the TDSOiterates the associated pseudo-random number generator for the PhysicalChannel (FCH/DCCH or SCH) one or more times, as specified in thefollowing subsections. For every synchronization frame, the serviceoption shall initiate the circular buffer. However, for ease ofimplementation, the actual number of random bits in a circular bufferthat is generated for a radio configuration is rounded to anoctet-aligned number of bits determined exactly by the minimum number ofiterations conducted on the associated pseudo-random number generator toachieve the given buffer size.

[0554] To generate the circular buffer at any rate R(n):

[0555] The service option shall generate a total of NUM_RANDpseudo-random numbers (as shown in Table 35) corresponding to actualcircular buffer size B(n).

[0556] Each 24-bit number y_(n) (k), 1≦k≦NUM_RAND, shall be reshuffledand stored in the little-endian order as shown in FIG. 2.

[0557] The reshuffled number y_(n)^(LE)(k)

[0558] has the least significant byte of y_(n) (k) in the mostsignificant byte position and vice versa

[0559]FIG. 2. Reshuffling of y_(n) (k) to generate y_(n)^(LE)(k)

[0560] For example, the 45-byte circular buffer (generated toaccommodate a needed buffer size of 344 bits) shall be comprised ofy_(n)^(LE)(1)

[0561] through y_(n)^(LE)(15)

[0562] as follows:y_(n)^(LE)(1), y_(n)^(LE)(2), y_(n)^(LE)(3)  …  y_(n)^(LE)(15)

TABLE 35 Procedure for generating the default circular buffers for RC>2channels Minumum required Actual number of 24-bit circular Neededcircular pseudo-random buffer size buffer size numbers Pseudo-random(bytes) R(n) NUM_RAND bits generated B(n)  344  15  15 × 24 = 360  45 534  23  23 × 24 = 552  69  6096  254  254 × 24 = 6096  762  9168  382 382 × 24 = 9168 1146 12240  510  510 × 24 = 12240 1530 18384  766  766× 24 = 18384 2298 24528 1022 1022 × 24 = 24528 3066 41424 1726 1726 × 24= 41424 5178

[0563] Information-bit generation for an N-frame circular buffer followsthe same method and principles as described for the 2-frame circularbuffer case.

[0564] Frame activity

[0565] If 5 ms FCH/DCCH frames are used, the TDSO shall decide whetheror not to request Layer 3 Signaling to send a mini message for each 5 msframe period based on the frame activity.

[0566] Otherwise, the TDSO passes the information bits to the multiplexsublayer according to a certain ON/OFF frame activity. For each frameperiod (20 ms, 40 ms, or 80 ms ) on a particular physical channel, theTDSO may choose to pass data block(s) corresponding to a full-rate frameon that channel or pass a blank data block to the multiplex sublayer.The TDSO shall support two different schemes to pass data to themultiplex sublayer, as follows:

[0567] Deterministic frame activity

[0568] This scheme is governed by the values of the TX_ON_PERIOD andTX_OFF_PERIOD indicated in the Service Option Control Message. Thefields represent (in units of 5 ms, 20 ms, 40 ms, or 80 ms, depending onthe target physical channel configuration) the pattern for passing datato the multiplex sublayer.

[0569] If the channel is an FCH/DCCH configured to use 5 ms frames, theTDSO shall:

[0570] Request Layer 3 Signaling to send an FSCAMM in the base station(or a SCRMM in the mobile station) every 5 ms, for a duration ofTX_ON_PERIOD.

[0571] Not request an FSCAMM in the base station (or a SCRMM in mobilestation) every 5 ms, for a duration of TX_OFF_PERIOD.

[0572] Otherwise, the TDSO shall:

[0573] Pass data blocks to the multiplex sublayer for a duration ofTX_ON_PERIOD.

[0574] Send blank data blocks for a duration of TX_OFF_PERIOD.

[0575] The ON/OFF cycle starts at the synchronization frame andterminates at the last frame before the next synchronization frame forthat channel.

[0576] Random with a specified frame activity and burst length

[0577] This second scheme is more random. Its goal is to achieve along-term average of a specified frame activity (D) and a specifiedburst length (B), which is defined as the average consecutive “On”period, for a channel. This goal is achieved by modeling the ON/OFFstates by a two-state first order Markov chain with transitionprobabilities p and q, as indicated in FIG. 3. The values of p and q arespecified in the ON_TO_OFF_PROB field and the OFF_TO_ON_PROB field,respectively, in the base-station control directive using the ServiceOption Control Message (see Table 39). The value of D can be calculatedbased on p and q as follows:

[0578] D=q/(p+q),

[0579] where p is the transition probability from the “On” state to the“Off” state, and q is the transition probability from the “Off” state tothe “On” state,

[0580] The average consecutive “On” period in units of frames, B, can becalculated follows:

[0581] B=1/p

[0582] Procedures for calculating p and q based on some desired D and Bare explained in Annex H.

[0583] FIG 3. Two-state Markov chain representing ON/OFF transitions forTDSO

[0584] A 24-bit pseudo-random number is used to drive the transitionsbetween the two TDSO states every frame period (5 ms, 20 ms, 40 ms, and80 ms). For all 20 ms frame length-based physical channels, the TDSOuses the same PN number generator, iterating every 20 ms to calculatethe transitions. If the operating Supplemental Channels are configuredfor 40 ms or 80 ms frame lengths, a second PN number generator iteratingevery 40 ms or 80 ms, respectively, is used to derive the TDSO state forthe Supplemental Channels.

[0585] The PN generator for the 5 ms, 20 ms frame length channels shallbe initialized at the first synchronization frame time after the TDSO isinitialized at the action time that is associated with the ServiceConnect Message. For the 40 ms or 80 ms frame lengths, the associated PNnumber generator shall be initialized at the first synchronization frametime after the TDSO is initialized on the Supplemental Channel at theaction time associated with the UHDM, ESCAM, FSCAMM, or RSCAMM. Wheninitialized, the state of the Markov chain shall be set to the “Off”state.

[0586] Normally, the state of the PN generators is maintained throughoutthe duration of the call without any reinitialization at thesynchronization frames. However, the PN generators are reinitialized ifa CDMA-CDMA hard handoff has been completed. In case of the latter, thereinitialization occurs at the first synchronization frame after thehandoff completion message. When reinitialized, the state of the Markovchain shall be set to the “Off” state.

[0587] Section 0 describes how the 24-bit PN number is derived. Themethod that is followed in choosing the TDSO state (ON or OFF) during aframe period is shown in FIG. 4.

[0588]FIG. 4. Flowchart illustrating TDSO state transitions for a Dframe activity and B average “On” period in units of frames.

[0589] Data block header and formats

[0590] In order to separate the calculation of FER on a per physicalchannel basis, a Channel ID must mark each data block that is suppliedto the multiplex sublayer during each frame interval.

[0591] Also, a sequence number is needed to help compare multiple PDUsthat carry individual data blocks received in a physical layer SDU witha locally generated frame.

[0592] The first 5 bits of each generated data block are replaced by theheader as shown in Table 36 for the FCH/DCCH and SCH Multiplex PDUs.TABLE 36 Data block format Field Length (bits) Definition CHANNEL_ID 2Channel ID of the underlying physical channel carrying the data block.Various channel codes are shown in Table 37. PDU_SEQ_NUM 3 Sequencenumber of the data block within a physical layer SDU. For FCH/DCCH datablocks, this field is set to ′000′. For SCH data blocks, this field isset as follows: It is set to ′000′ for the first data block (MuxPDU) inthe SCH frame, ′001′ for the second data block in the SCH frame, and soon. DATA Variable up Data bits as generated according to to the data theselected DATA_SOURCE block size algorithm.

[0593] TABLE 37 CHANNEL_ID type codes CHANNEL_ID Traffic channel ′00′FCH ′01′ DCCH ′10′ SCH0 ′11′ SCH1

[0594] Message formats

[0595] Service Option Control Message

[0596] If the base station or mobile station sends a Service OptionControl Message, it shall set the CTL_REC_TYPE field to the value shownin Table 38 corresponding to the desired directive. TABLE 38CTL_REC_TYPE codes CTL_REC_TYPE Type of directive ′00000000′ ControlDirective for all Physical Channels carrying TDSO traffic ′00000001′Control Directive for FCH ′00000010′ Control Directive for DCCH′00000011′ Control Directive for SCH0 ′00000100′ Counter Directive forSCH1 ′00000101′ Counter Retrieval Directive for FCH ′00000110′ CounterRetrieval Directive for DCCH ′00000111′ Counter Retrieval Directive forSCH0 ′00001000′ Counter Retrieval Directive for SCH1′00001001′-′11111111′ Reserved

[0597] Control

[0598] When the mobile station sends a Service Option Control Message topropose control action or the base station sends a Service OptionControl Message to invoke control action in a mobile station, it shallinclude the type-specific fields as specified in Table 39. TABLE 39Serivce Option Control Message type-specific fields Length Field (bits)Definition CTL_REC_TYPE 8 Control record type field(′00000000′-′00000100′) The mobile station or base station shall setthis field to a value between ′00000000′ and ′00000100′ to signify acontrol directive on all TDSO-configured channels or for a specificchannel according to Table 38. CONTROL_CODE 8 Control code field. Themobile station or base station shall set this field according to Table40. CHANNEL_(—) 2 Channel direction field. DIRECTION This fieldindicates what channel direction this control directive is for. The basestation or mobile station shall set this field according to Table 43.COPY_COUNTERS 1 Copy counters field. If the mobile station or basestation are to copy the counter values at the next synchronizationframe, the base station shall set this field to ′1′. Otherwise, the basestation shall set this field to ′0′. CLEAR_COUNTERS 1 Clear countersfield. If the mobile station and base station are to clear the countersat the next synchronization frame, the base station shall set this fieldto ′1′. Otherwise, the base station shall set this field to ′0′.DATA_SOURCE 1 Data source field. The mobile station or base stationshall set this field to the DATA_(—) SOURCE value shown in Table 42corresponding to the type of traffic that is desired to be generatedduring the test call. FRAME_SOURCE 2 Frame source field. Through thisfield, the base station or mobile station defines the source to be usedfor filling up the data frames for the particular channel. The variousoptions are indicated in Table 44. FRAME_ACTIVITY 1 Frame activityfield. The base station or mobile station shall set this field to theFRAME_(—) ACTIVITY value shown in Table 42 corresponding to the desiredburst- iness in the traffic that is to be generated during the testcall. TEST_OPTIONS 8 TDSO Test Options. The base station or mobilestation shall set this field according to Table 45. NUM_CIRC_BUF_(—) 0or 8 Number of full-rate frames in the FRAMES circular buffer field. Themobile station or base station shall set this field to indicate thedesired size of the circular buffer frames. This field is present onlyif the FRAME_SOURCE field is set to ′01′. If the control directive is amobile station proposal and the base station cannot support the proposedbuffer size, the base station shall set this field to the maximum numberof frames it can support during that call for that channel.ON_TO_OFF_PROB 0 or 8 “On” state to “Off” state transition probabilityfield. This frame is only present if the FRAME_ACTIVITY field has avalue of 1. The base station or mobile station shall set this field tothe ROUND(Desired “On” to “Off” state transition probability * 100). Thevalid range for this field is between ′00000000′ and ′01100100′.OFF_TO_ON_PROB 0 or 8 “Off” state to “On” state transition probabilityfield. This frame is only present if the FRAME_ACTIVITY field has avalue of 1. The base station or mobile station shall set this field tothe ROUND(Desired “Off” to “On” state transition probability * 100). Thevalid range for this field is between ′00000000′ and ′01100100′.TX_ON_PERIOD 0 or 8 Transmission on period field. This frame is onlypresent if the FRAME_ACTIVITY field has a value of 0. The base stationor mobile station shall set this field to the desired number of adjacentframe periods (20 ms, 40 ms, or 80 ms). The TDSO shall supply non- blankdata frames to the multiplex sublayer before passing blank frames to itfor the number of frame periods indicated by the TX_OFF_(—) PERIODfield. TX_OFF_PERIOD 0 or 8 Transmission off period field. This frame isonly present if the FRAME_ACTIVITY field has a value of ′0′. The basestation or mobile station shall set this field to the desired number ofadjacent frame periods (20 ms, 40 ms, or 80 ms). The TDSO shall supplyblank frames to the multiplex sublayer after passing non-blank frames toit for the number of frame periods indicated by the TX_ON_PERIOD field.DATA_PATTERN 0 or 8 Data pattern field. This frame is only present ifthe DATA_SOURCE field has a value of ′0′. The mobile station or basestation shall set this field to the selectable byte pattern to be usedfor the test corresponding to the type of traffic that is generatedduring the test call.

[0599] TABLE 40 CONTROL_CODE codes CONTROL_CODE Meaning ‘00000000’Mobile station proposed control directive ‘00000001’ Base stationcontrol directive ‘00000010’ Base station control directive based onmobile station proposal ‘00000011’ Base station control directive basedon mobile station proposal (number of frames in circular buffer notsupported - NUM_CIRC_BUF_FRAMES field indicates maximum number of framesbase station can support) ‘00000100’ Base station control directivebased on mobile station proposal (message cannot be handled by thecurrent base station configuration) ‘00000101’ Base station controldirective based on mobile station proposal (message structure notacceptable) ‘00000110’ Base station control directive based on mobilestation proposal (unable to support a value of ‘10’ for the FRAME_SOURCEfield as indicated in TABLE 44, that is, cannot generate 1 frame eachframe period) ‘00000111’-‘11111111’ Reserved

[0600] TABLE 41 DATA_SOURCE codes DATA_SOURCE Traffic pattern ‘0’Selectable data pattern ‘1’ Pseudo-random bits

[0601] TABLE 42 FRAME_ACTIVITY codes FRAME_ACTIVITY Type ‘0’Deterministic frame activity ‘1’ Random frame activity

[0602] TABLE 43 CHANNEL_DIRECTION codes CHANNEL_DIRECTION Channel types‘00’ Both forward and reverse link ‘01’ Forward link direction only ‘10’Reverse link direction only ‘11’ Reserved

[0603] TABLE 44 FRAME_SOURCE codes FRAME_SOURCE Circular buffercomposition ‘00’ 2 full-rate frames ‘01’ N full-rate frames ‘10’ Newframe every frame period (20 ms, 40 ms, or 80 ms) ‘11’ Reserved

[0604] TABLE 45 TEST_OPTIONS codes TEST_OPTIONS TDSO Test Options‘00000000’-‘11111111’ Reserved

[0605] Counter retrieval

[0606] When the base station or mobile station sends a Service OptionControl Message to retrieve counter values from the other end for any ofthe Fundicated channels (FCH/DCCH), it shall include the type-specificfields as specified in Table 46. TABLE 46 Type-specific fields in aService Option Control Message used for counter retrieval on theFCH/DCCH Length Field (bits) Definition CTL_REC_TYPE 8 Control recordtype field. (“00000101’or The mobile station or base station shall set“00000110’) this field to ‘00000101’ to signify a counter retrievaldirective on the FCH and ‘00000110’ to signify a counter retrievaldirective on the DCCH. VECT_COUNTER_ID 8 Vector counter identificationfield. The base station or mobile station shall set this field tocorrespond to the value shown in TABLE 47 for the Fundicated Channelsand in corresponding to the desired vector of counter values.

[0607] TABLE 47 VECT_COUNTER_ID codes for FCH/DCCH VECT_COUNTER_IDVector name ‘00000000’ FER counters ‘00000001’ Receive Expected CountersResponse ‘00000010’ Transmitted counters ‘00000011’ 5 ms FrameTransmitted counters ‘00000100’ 5 ms Frame Received counters ‘00000101’-Reserved ‘11111111’

[0608] When the base station or mobile station sends a Service OptionControl Message to retrieve counter values from the other end for theSCHs, it shall include the type-specific fields as specified in Table48. TABLE 48 Type-specific fields in a Service Option Control Messageused for counter retrieval from the mobile station for SCHs Length Field(bits) Definition CTL_REC_TYPE 8 Control record type field. (‘00000111’or The base station or mobile station shall set this ‘00001000’) fieldto signify a counter retrieval directive on the Supplemental Channels.For the SCH0 and SCH1 channels, the field shall be set to ‘00000111’ and‘00001000’, respectively. VECT_COUNTER_ID 8 Vector counteridentification field. The base station or mobile station shall set thisfield to correspond to the value shown in TABLE 49 corresponding to thedesired vector of counter values.

[0609] TABLE 49 VECT_COUNTER_ID codes for SCHs VECT_COUNTER_ID Vectorname ‘00000000’ FER counters response ‘00000001’ PER ‘00000010’Transmitted counters response ‘00000011’- Reserved ‘11111111’

[0610] Counter responses on the fundicated channels

[0611] FER Counters Response

[0612] When the mobile station or base station sends a FER CountersResponse for the FCH or DCCH channels, it shall include the followingtype-specific fields in the Service Option Control Message: TABLE 50Type-specific fields in a Service Option Control Message correspondingto FER Counters Response on FCH/DCCH Length Field (bits) DefinitionCTL_REC_TYPE  8 Control record type field. (′00000101′ or The mobilestation or base station ′00000110′) shall set this field to ′00000101′when responding to an FCH Control directive and ′00000110′ for DCCH.VECT_COUNTER_ID  8 Vector counter identification field. (′00000000′) Themobile station or base station shall set this field to ′00000000′.TDSO_E1_R1 24 Counter for Rate 1 data blocks received error free. Themobile station shall set this field to the value of TDSO_E1_R1 stored inthe FFCH_BUFFER or FDCCH_BUFFER modulo 2^(24.) The base station shallset this field to the value of TDSO_E1_R1 stored in the RFCH_BUFFER orRDCCH_BUFFER modulo 2^(24.) TDSO_E1_RBAD 24 Number of Rate 1 data blocksreceived in error. The mobile station shall compute this value usingcounter values stored in the FFCH_BUFFER or FDCCH_BUFFER as follows:TDSO_E1_RBAD = (TDSO_E1_RERR + TDSO_E1_RD + TDSO_E1_RE + TDSO_E1_RO +TDSO_E1_RB + TDSO_E1_RFL) mod 2²⁴. The base station shall compute thisvalue using counter values stored in the RFCH_BUFFER or RDCCH_BUFFER asfollows: TDSO_E1_RBAD = (TDSO_E1_RERR + TDSO_E1_RD + TDSO_E1_RE +TDSO_E1_RO + TDSO_E1_RB + TDSO_E1_RFL) mod 2²⁴. TDSO_EN_RN 24 Counterfor blank frames received as null frames. The mobile station shall setthis field to the value of TDSO_EN_RN stored in the FFCH_BUFFER orFDCCH_(—) BUFFER modulo 2^(24. The base station) shall set this field tothe value of TDSO_EN_RN stored in the RECH_BUFFER/RDCCH_(—) BUFFERmodulo 2^(24.) TDSO_EN_RBAD 24 Number of null data blocks received inerror. The mobile station shall compute this value using counter valuesstored in the FFCH_BUFFER or FDCCH_BUFFER as follows: TDSO_EN_RBAD =(TDSO_EN_RB + TDSO_EN_RO) mod 2^(24.) The base station shall computethis value using counter values stored in the RFCH_BUFFER orRDCCH_BUFFER as follows: TDSO_EN_RBAD = (TDSO_EN_RB + TDSO_EN_RO) mod2^(24.) TDSO_Ex_RBAD 24 Number of bad overall data blocks. The mobilestation shall compute this value using counter values stored in theFFCH_BUFFER or FDCCH_BUFFER as follows: TDSO_Ex_RBAD = (TDSO_E1_RBAD +TDSO_EN_RB + TDSO_EN_RO) mod 2^(24.) The base station shall compute thisvalue using counter values stored in the RFCH_BUFFER or RDCCH_BUFFER asfollows: TDSO_Ex_RBAD = (TDSO_E1_RBAD + TDSO_EN_RB + TDSO_EN_RO) mod2^(24.)

[0613] Receive Expected Counters Response

[0614] When the mobile station or base station sends a Receive ExpectedCounters Response, it shall include the following type-specific fieldsin the Service Option Control Message: TABLE 51 Type-specific fields ina Service Option Control Message corresponding to Receive ExpectedCounters Response on FCH/DCCH Length Field (bits) DefinitionCTL_REC_TYPE  8 Control record type field. (′00000101′ or The mobilestation or base station ′00000110′) shall set this field to ′00000101′when responding to an FCH Control directive and ′00000110′ for DCCH.VECT_COUNTER_ID  8 Vector counter identification field. (′00000001′) Themobile station shall set this field to ′00000001′. TDSO_E1_R1 24 Counterfor Rate 1 frames received error-free. The mobile station shall set thisfield to the value of TDSO_E1_R1 stored in the FFCH_BUFFER orFDCCH_BUFFER modulo 2^(24.) The base station shall set this field to thevalue of TDSO_E1_R1 stored in the RFCH_BUFFER or RDCCH_BUFFER modulo2^(24.) TDSO_E1_RD 24 Counter for the number of dim-and- burst framesreceived given that the expected data block was Rate 1. The mobilestation shall set this field to the value of TDSO_E1_RD stored in theFFCH_BUFFER or FDCCH_BUFFER, modulo 2²⁴. The base station shall set thisfield to the value of TDSO_E1_RD stored in the RFCH_BUFFER orRDCCH_BUFFER, modulo 2²⁴. TDSO_E1_RO 24 Counter for the number of anyother frames received (excluding dim-and- burst types) given that theexpected data block was Rate 1. The mobile station shall set this fieldto the value of TDSO_E1_RO stored in the FFCH_BUFFER or FDCCH_BUFFER,modulo 2²⁴. The base station shall set this field to the value ofTDSO_E1_RO stored in the RFCH_BUFFER or RDCCH_BUFFER, modulo 2²⁴.TDSO_E1_RB 24 Counter for the number of blank-and- burst frames receivedgiven that the expected data block was Rate 1. The mobile station shallset this field to the value of TDSO_E1_RB stored in the FFCH_BUFFER orFDCCH_BUFFER, modulo 2²⁴. The base station shall set this field to thevalue of TDSO_E1_RB stored in the RFCH_BUFFER or RDCCH_BUFFER, modulo2²⁴. TDSO_E1_RFL¹ 24 Counter for the number of Rate 1 frames with biterrors received (a categorization only applicable with the Multiplexoption²) given that the expected data block was Rate 1. The mobilestation shall set this field to the value of TDSO_E1_RFL stored in theFFCH_BUFFER or FDCCH_BUFFER, modulo 2²⁴. The base station shall set thisfield to the value of TDSO_E1_RFL stored in the RFCH_BUFFER orRDCCH_BUFFER, modulo 2²⁴. TDSO_E1_RE 24 Counter for the number of framesreceived with Insufficient frame quality (erasure) given that theexpected data block was Rate 1. The mobile station shall set this fieldto the value of TDSO_E1_RE stored in the FFCH_BUFFER or FDCCH_BUFFER,modulo 2²⁴. The base station shall set this field to the value ofTDSO_E1_RE stored in the RFCH_BUFFER or RDCCH_BUFFER, modulo 2²⁴.TDSO_E1_RERR 24 Counter for the number of Rate 1 frames received withbit errors (detected by the TDSO) given that the expected data block wasRate 1. The mobile station shall set this field to the value ofTDSO_E1_RERR stored in the FFCH_BUFFER or FDCCH_BUFFER, modulo 2²⁴. Thebase station shall set this field to the value of TDSO_E1_RERR stored inthe RFCH_BUFFER or RDCCH_BUFFER, modulo 2²⁴. TDSO_EN_RN 24 Counter forthe number of null frames received given that the expected data blockwas also null. The mobile station shall set this field to the value ofTDSO_EN_RN stored in the FFCH_BUFFER or FDCCH_BUFFER, modulo 2²⁴. Thebase station shall set this field to the value of TDSO_EN_RN stored inthe RFCH_BUFFER or RDCCH_BUFFER, modulo 2²⁴. TDSO_EN_RB 24 Counter forthe number of blank frames received given that the expected data blockwas null. The mobile station shall set this field to the value ofTDSO_EN_RB stored in the FFCH_BUFFER or FDCCH_BUFFER, modulo 2²⁴. Thebase station shall set this field to the value of TDSO_EN_RB stored inthe RFCH_BUFFER or RDCCH_BUFFER, modulo 2²⁴. TDSO_EN_RO 24 Counter forthe number of other categories of MuxPDU received given that theexpected frame was null. The mobile station shall set this field to thevalue of TDSO_EN_RO stored in the FFCH_BUFFER or FDCCH_BUFFER, modulo2²⁴. The base station shall set this field to the value of TDSO_EN_ROstored in the RFCH_BUFFER or RDCCH_BUFFER, modulo 2²⁴.

[0615] Transmitted Counters Response

[0616] When the mobile station or base station sends a TransmittedCounters Response, it shall include the following type-specific fieldsin the Service Option Control Message: TABLE 52 Type-specific fields ina Service Option Control Message corresponding to Transmitted CountersResponse on FCH/DCCH Length Field (bits) Definition CTL_REC_TYPE  8Control record type field. (′00000101′ or The mobile station or basestation ′00000110′) shall set this field to ′00000101′ when respondingto an FCH Control directive and ′00000110′ for DCCH. VECT_COUNTER_ID  8Vector counter identification field. (′00000001′) The mobile station orbase station shall set this field to ′00000001′. TDSO_E1_T1 24 Counterfor Rate 1 frames transmitted with no dim-and-burst or blank-and- burstgiven that the generated data block was Rate 1. The mobile station shallset this field to the value of TDSO_E1_T1 stored in the RFCH_BUFFER orRDCCH_BUFFER modulo 2^(24.) The base station shall set this field to thevalue of TDSO_E1_T1 stored in the FFCH_BUFFER or FDCCH_BUFFER modulo2^(24.) TDSO_E1_TD 24 Counter for the number of dim-and- burst framestransmitted, given that the generated data block was Rate 1. The mobilestation shall set this field to the value of TDSO_E1_TD stored in theRFCH_BUFFER or RDCCH_BUFFER, modulo 2²⁴. The base station shall set thisfield to the value of TDSO_E1_TD stored in the FFCH_BUFFER orFDCCH_BUFFER, modulo 2²⁴. TDSO_E1_TB 24 Counter for the number ofblank-and- burst frames transmitted, given that the generated data blockwas Rate 1. The mobile station shall set this field to the value ofTDSO_E1_TB stored in the RFCH_BUFFER or RDCCH_BUFFER, modulo 2²⁴. Thebase station shall set this field to the value of TDSO_E1_TB stored inthe FFCH_BUFFER or FDCCH_BUFFER, modulo 2²⁴. TDSO_EB_TB 24 Counter forthe number of blank-and- burst frames transmitted, given that thegenerated data block was Rate 1. The mobile station shall set this fieldto the value of TDSO_EB_TB stored in the RFCH_BUFFER or RDCCH_BUFFER,modulo 2²⁴. The base station shall set this field to the value ofTDSO_EB_TB stored in the FFCH_BUFFER or FDCCH_BUFFER, modulo 2²⁴.TDSO_EB_TO 24 Counter for the number of other frame types transmitted,given that the generated data block was (basically, the counter for theevent when the TDSO wants to transmit a blank and the multiplex sublayeralso requests a blank frame for the particular frame period). The mobilestation shall set this field to the value of TDSO_EB_TO stored in theRFCH_BUFFER or RDCCH_BUFFER, modulo 2²⁴. The base station shall set thisfield to the value of TDSO_EB_TO stored in the FFCH_BUFFER orFDCCH_BUFFER, modulo 2²⁴.

[0617] 5 ms Frame Transmitted Counters Response

[0618] When the mobile station sends a 5 ms Frame Transmitted CountersResponse, it shall include the following type-specific fields in theService Option Control Message: TABLE 53 Type-specific fields in aService Option Control Message corresponding to 5 ms Frame TransmittedCounters Response on FCH/DCCH Length Field (bits) DefinitionCTL_REC_TYPE  8 Control record type field. (′00000101′ or The mobilestation or base station ′00000110′) shall set this field to ′00000101′when responding to an FCH Control directive and ′00000110′ for DCCH.VECT_COUNTER_ID  8 Vector counter identification field. (′00000001′) Themobile station shall set this field to ′00000001′. TDSO_MUX1_(—) 24Counter for 5 ms transmitted. 5ms_T1 If CTL_REC_TYPE is set to′00000101′, the mobile station shall set this field to the value ofMUX1_REV_FCH_5_ms (see [5]) stored in mobile station, modulo 2²⁴, at theACTION_TIME specified by this Service Option Control Message. Otherwise,the mobile station shall set this field to the value ofMUX1_REV_DCCH_5_ms (see [5]) stored in mobile station, modulo 2²⁴, atACTION_TIME specified by this Service Option Control Message.TDSO_MUX2_(—) 24 Counter for 5 ms transmitted. 5ms_T1 If CTL_REC_TYPE isset to ′00000101′, the mobile station shall set this field to the valueof MUX2_REV_FCH_5_ms (see [5]) stored in mobile station, modulo 2²⁴, atthe ACTION_TIME specified by this Service Option Control Message.Otherwise, the mobile station shall set this field to the value ofMUX2_REV_DCCH_5_ms (see [5]) stored in mobile station, modulo 2²⁴, atACTION_TIME specified by this Service Option Control Message.

[0619] 5 ms Frame Received Counters Response

[0620] When the mobile station sends a 5 ms Frame Received CountersResponse, it shall include the following type-specific fields in theService Option Control Message: TABLE 54 Type-specific fields in aService Option Control Message corresponding to 5 ms Frame ReceivedCounters Response on FCH/DCCH Length Field (bits) DefinitionCTL_REC_TYPE  8 Control record type field. (′00000101′ or The mobilestation or base station ′00000110′) shall set this field to ′00000101′when responding to an FCH Control directive and ′00000110′ for DCCH.VECT_COUNTER_ID  8 Vector counter identification field. (′00000001′) Themobile station shall set this field to ′00000001′. TDSO_MUX1_(—) 24Counter for 5 ms received. 5ms_R1 If CTL_REC_TYPE is set to ′00000101′,the mobile station shall set this field to the value ofMUX1_FOR_FCH_5_ms (see [5]) stored in mobile station, modulo 2²⁴, at theACTION_TIME specified by this Service Option Control Message. Otherwise,the mobile station shall set this field to the value ofMUX1_FOR_DCCH_5_ms (see [5]) stored in mobile station, modulo 2²⁴, atACTION_TIME specified by this Service Option Control Message.TDSO_MUX2_(—) 24 Counter for 5 ms received. 5ms_R1 If CTL_REC_TYPE isset to ′00000101′, the mobile station shall set this field to the valueof MUX2_FOR_FCH_5_ms (see [5]) stored in mobile station, modulo 2²⁴, atthe ACTION_TIME specified by this Service Option Control Message.Otherwise, the mobile station shall set this field to the value ofMUX2_FOR_DCCH_5_ms (see [5]) stored in mobile station, modulo 2²⁴, atACTION_TIME specified by this Service Option Control Message.

[0621] Counter responses on the Supplemental Channels

[0622] FER counters response

[0623] When the mobile station or base station sends an FER CountersResponse, it shall include the following type-specific fields in theService Option Control Message: TABLE 55 Type-specific fields in aService Option Control Message corresponding to FER Counters Response onSCH(s) Length Field (bits) Definition CTL_REC_TYPE  8 Control recordtype field. (′00000111′ or The mobile station shall set this ′00001000′)field to ′00000111′ or ′00001000′, repectively, when responding to anSCH0 or SCH1 control directive. VECT_COUNTER_ID  8 Vector counteridentification field. (′00000000′) The mobile station or base stationshall set this field to ′00000000′. TDSO_ENx_RNx 24 Counter for Nx9.6 orNx14.4 frames received error-free. The mobile station shall set thisfield to the value of TDSO_ENx_RNx stored in the FSCH0_BUFFER orFSCH1_BUFFER, modulo 2²⁴. The base station shall set this field to thevalue of TDSO_ENx_RNx stored in the RSCH0_BUFFER or RSCH1_BUFFER, modulo2²⁴. TDSO_ENx_RBAD 24 Number of bad frames received instead of Nx9.6 orNx14.4 frames. The mobile station shall compute this value using countervalues stored in the FSCH0_BUFFER or FSCH1_BUFFER as follows:TDSO_ENx_RBAD = (TDSO_ENx_RERR + TDSO_ENx_RE + TDSO_ENx_RB) mod 2²⁴. Thebase station shall compute this value using counter values stored in theRSCH0_BUFFER or RSCH1_BUFFER as follows: TDSO_ENx_RBAD =(TDSO_ENx_RERR + TDSO_ENx_RE + TDSO_ENx_RB) mod 2²⁴. TDSO_EB_RB 24Counter for blank frames received as blank frames. The mobile stationshall set this field to the value of TDSO_EB_RB stored in theFSCH0_BUFFER or FSCH1_BUFFER, modulo 2²⁴. The base station shall setthis field to the value of TDSO_EB_RB stored in the RSCH0_BUFFER orRSCH1_BUFFER, modulo 2²⁴. TDSO_EB_RBAD 24 Number of bad frames receivedinstead of blank frames. The mobile station shall compute this valueusing counter values stored in the FSCH0_BUFFER or FSCH1_BUFFER asfollows: TDSO_EB_RBAD = (TDSO_EB_RO) mod 2²⁴. The base station shallcompute this value using counter values stored in the RSCH0_BUFFER orRSCH1_BUFFER as follows: TDSO_EB_RBAD = (TDSO_EB_RO) mod 2²⁴.TDSO_Ex_RBAD 24 Number of bad overall frames. The mobile station shallcompute this value using counter values stored in the FSCH0_BUFFER orFSCH1_BUFFER as follows: TDSO_E1_RBAD = (TDSO_ENx_RBAD + TDSO_EB_RO) mod2²⁴. The base station shall compute this value using counter valuesstored in the RSCH0_BUFFER or RSCH1_BUFFER as follows: TDSO_E1_RBAD =(TDSO_ENx_RBAD + TDSO_EB_RO) mod 2²⁴.

[0624] PER Counters Response

[0625] When the mobile station or base station sends a PER CountersResponse, it shall include the following type-specific fields in theService Option Control Message: TABLE 56 Type-specific fields in aService Option Control Message corresponding to PER Counters Response onSCH(s) Length Field (bits) Definition CTL_REC_TYPE  8 Control recordtype field. (′00000111′ or The mobile station shall set this ′00001000′)field to ′00000111′ or ′00001000′, repectively, when responding to anSCH0 or SCH1 control directive. VECT_COUNTER_ID  8 Vector counteridentification field. (′00000001′) The mobile station shall set thisfield to ′00000001′. TDSO_E3_R3 24 Counter for Rate 3 frames receivederror-free. The mobile station shall set this field to the value ofTDSO_E3_R3 stored in the FSCH0_BUFFER or FSCH1_BUFFER, modulo 2²⁴. Thebase station shall set this field to the value of TDSO_E3_R3 stored inthe RSCH0_BUFFER or RSCH1_BUFFER, modulo 2²⁴. TDSO_E3_RERR 24 Counterfor Rate 3 frames received with errors detected by the TDSO. The mobilestation shall set this field to the value of TDSO_E3_RERR stored in theFSCH0_BUFFER or FSCH1_BUFFER, modulo 2²⁴. The base station shall setthis field to the value of TDSO_E3_RERR stored in the RSCH0_BUFFER orRSCH1_BUFFER, modulo 2²⁴. TDSO_E3_RE 24 Counter for expected Rate 3frames received as erasures. The mobile station shall set this field tothe value of TDSO_E3_RE stored in the FSCH0_BUFFER or FSCH1_BUFFER,modulo 2²⁴. The base station shall set this field to the value ofTDSO_E3_RE stored in the RSCH0_BUFFER or RSCH1_BUFFER, modulo 2²⁴.TDSO_E2_R2 24 Counter for Rate 2 frames received error-free. The mobilestation shall set this field to the value of TDSO_E2_R2 stored in theFSCH0_BUFFER or FSCH1_BUFFER, modulo 2²⁴. The base station shall setthis field to the value of TDSO_E2_R2 stored in the RSCH0_BUFFER orRSCH1_BUFFER, modulo 2²⁴. TDSO_E2_RERR 24 Counter for Rate 2 framesreceived with errors detected by the TDSO. The mobile station shall setthis field to the value of TDSO_E2_RERR stored in the FSCH0_BUFFER orFSCH1_BUFFER, modulo 2²⁴. The base station shall set this field to thevalue of TDSO_E2_RERR stored in the RSCH0_BUFFER or RSCH1_BUFFER, modulo2²⁴. TDSO_E2_RE 24 Counter for expected Rate 2 frames received aserasures. The mobile station shall set this field to the value ofTDSO_E2_RE stored in the FSCH0_BUFFER or FSCH1_BUFFER, modulo 2²⁴. Thebase station shall set this field to the value of TDSO_E2_RE stored inthe RSCH0_BUFFER or RSCH1_BUFFER, modulo 2²⁴. TDSO_E1a_R1a 24 Counterfor Rate 1a frames received error-free. The mobile station shall setthis field to the value of TDSO_E1a_R1a stored in the FSCH0_BUFFER orFSCH1_BUFFER, modulo 2²⁴. The base station shall set this field to thevalue of TDSO_E1a_R1a stored in the RSCH0_BUFFER or RSCH1_BUFFER, modulo2²⁴. TDSO_E1a_RERR 24 Counter for Rate 1a frames received with errorsdetected by the TDSO. The mobile station shall set this field to thevalue of TDSO_E1a_RERR stored in the FSCH0_BUFFER or FSCH1_BUFFER,modulo 2²⁴. The base station shall set this field to the value ofTDSO_E1a_RERR stored in the RSCH0_BUFFER or RSCH1_BUFFER, modulo 2²⁴.TDSO_E1a_RE 24 Counter for expected Rate 1a frames received as erasures.The mobile station shall set this field to the value of TDSO_E1a_REstored in the FSCH0_BUFFER or FSCH1_BUFFER, modulo 2²⁴. The base stationshall set this field to the value of TDSO_E1a_RE stored in theRSCH0_BUFFER or RSCH1_BUFFER, modulo 2²⁴. TDSO_E1b_R1b 24 Counter forRate 1b frames received error-free. The mobile station shall set thisfield to the value of TDSO_E1b_R1b stored in the FSCH0_BUFFER orFSCH1_BUFFER, modulo 2²⁴. The base station shall set this field to thevalue of TDSO_E1b_R1b stored in the RSCH0_BUFFER or RSCH1_BUFFER, modulo2²⁴. TDSO_E1b_RERR 24 Counter for Rate 1b frames received with errorsdetected by the TDSO. The mobile station shall set this field to thevalue of TDSO_E1b_RERR stored in the FSCH0_BUFFER or FSCH1_BUFFER,modulo 2²⁴. The base station shall set this field to the value ofTDSO_E1b_RERR stored in the RSCH0_BUFFER or RSCH1_BUFFER, modulo 2²⁴.TDSO_E1b_RE 24 Counter for expected Rate 1b frames received as erasures.The mobile station shall set this field to the value of TDSO_E1b_REstored in the FSCH0_BUFFER or FSCH1_BUFFER, modulo 2²⁴. The base stationshall set this field to the value of TDSO_E1b_RE stored in theRSCH0_BUFFER or RSCH1_BUFFER, modulo 2²⁴.

[0626] Transmitted Counters response

[0627] When the mobile station or base station sends a TransmittedCounters Response, it shall include the following type-specific fieldsin the Service Option Control Message: TABLE 57 Type-specific fields ina Service Option Control Message corresponding to Transmitted Countersresponse on SCH(s) Length Field (bits) Definition CTL_REC_TYPE  8Control record type field. {′00000111′ or The mobile station shall setthis ′00001000′) field to ′00000111′ or ′00001000′, repectively, whenresponding to an SCH0 or SCH1 control directive. VECT_COUNTER_ID  8Vector counter identification field. (′00000010′) The mobile station orbase station shall set this field to ′00000010′. TDSO_ENx_TNx 24 Counterfor Rate Nx9.6 or Rate Nx14.4 frames transmitted with no blank commandfrom the multiplex sublayer. The mobile station shall set this field tothe value of TDSO_ENx_TNx stored in the RSCH0_BUFFER or RSCH1_BUFFER,modulo 2²⁴. TDSO_ENx_TB 24 Counter for the number of blank framestransmitted given that the generated frame was Rate Nx9.6 or RateNx14.4. The mobile station shall set this field to the value ofTDSO_ENx_TB stored in the in the RSCH0_(—) BUFFER or RSCH1_BUFFER,modulo 2²⁴. TDSO_EB_TO 24 Counter for the number of other frame typestransmitted given that the generated frame was blank (basically, thecounter for the event when the TDSO wants to transmit a blank and themultiplex sublayer also requests a blank frame for the particular frameperiod). The mobile station shall set this field to the value ofTDSO_EB_TO stored in the RSCH0_BUFFER or RSCH1_BUFFER, modulo 2²⁴.

[0628] TDSO Call Flow Examples (for a system operating in MC-41 mode)

[0629] This annex contains examples of TDSO call flows using servicenegotiation.

[0630]FIG. 5 to FIG. 7 use the following convention:

[0631] All messages are received without error.

[0632] Acknowledgments are not shown. Mobile Station Base StationDetects user-initiated call Sends Origination > r-csch > Sets upFundicated Message specifying the Traffic Channel(s). TDSO serviceoption. Begins sending null Traffic Channel data. Sets up Fundicated <f-csch < Sends Extended Traffic Channel. Channel Assignment ReceivesN_(5m) Message. consecutive valid frames. Begins sending the > r-dtch >Acquires the Reverse Traffic Channel Fundicated Traffic preamble.Channel. Begins transmitting null < f-dsch < Sends Base Station TrafficChannel data. Acknowledgment Order. < Service > Negotiation r/f-dsch <f-dsch < Sends Service Connect Message. Sends Service Connect > r-dsch >Completion Message. (Continued on next page) (Continued on next page)

[0633]FIG. 5. Mobile station origination example with transmission onDCCH/FCH/SCH (part 1 of 2) Mobile Station Base Station Enters theConversation < dsch/dtch > Connect and Substate, and connectsinitialized the TDSO the TDSO service option service option at theaction time following the action specified in the time specified inService Connect Message. the Service Connect Generates Rate 1 framesMessage. (by default all 1s) from the time of service option connectionto the first synchronization frame. At the first synchronization frame,resynchronized the TDSO. Sends Supplemental > r-dsch > Channel RequestMessage and continues transmitting on the Reverse Traffic Channel. <f-dsch/ > Allocates f-dtch Supplemental Channel(s) through ESCAM,FSCAMM, RSCAMM, or UHDM. Connects the TDSO at < dsch/dtch > Connects andthe action time initialized the specified in the TDSO service SCHallocation message. option following Generates Rate 1 frames the actiontime (by default all 1s) from specified in the the time of serviceESCAM, FSCAMM, option connection to RSCAMM, or UHDM. the frame prior tothe Continues first synchronization transmission on the frame. At thefirst Forward Funicated synchronization frame Channels. resynchronizesthe TDSO. Continues transmitting on the Reverse Fundicated Channels.(TDSO Traffic) (TDSO Traffic)

[0634]FIG. 6. Mobile station origination example with transmission onDCCH/FCH/SCH (part 2 of 2) Mobile Station Base Station (TDSO CallActive) (TDSO Call Active) < f-dsch/dtch < Sends Service Option ControlMessage specifying a new type of data source and/or transmission frameactivity on the Supplemental Channel. Sends an > r-dsch/dtch >acknowledgement. Accepts the new fields. Starts processing Startsprocessing using TDSO traffic using the new data source the new datasource and/or frame activity and/or frame activity specified in the fromthe next Service Option synchronization Control Message frame on thefrom the next Supplemental synchronization Channel. Continues frame onthe to use the same specified Supplemental TDSO configuration Channel.Continues on the Fundicated to use the same channel. TDSO configurationon the Fundicated channels. (TDSO Traffic) (TDSO Traffic)

[0635]FIG. 7. Base station commanded test parameters change

[0636] No text.

[0637] TDSO Operation Examples

[0638] B.1 A TDSO scenario

[0639] This annex provides two examples of TDSO test scenarios. Assumethe following:

[0640] The TDSO is configured to carry primary traffic over the FCH inboth forward and reverse directions and on SCHO in only the forwarddirection.

[0641] The mobile station and base station are configured to support theRC3 configuration for the test setup.

[0642] The TDSO is passing pseudo-randomly generated data blocks to themux sublayer per Multiplex Option 0x01 on the FCH (that is, one MuxPDUType 1 data block can be passed to the multiplex sublayer every 20 ms).

[0643] SCHO is configured for 20 ms frame length, has been allocated tosupport 19.2 kbps, and carries TDSO-generated pseudo-random data bitsper Multiplex Option 0x809 format (that is, two single-sized MuxPDU Type3 data blocks can be supplied to the multiplex sublayer every 20 ms).

[0644] p is equal to 0.7 and q is equal to 0.3. Then, D=q/(p+q)=0.3,B=1/p≈1.4, OFF_THRESHOLD=ROUND(16777215 * p)=11744051 andON_THRESHOLD=ROUND(16777215 * q)=5033164.

[0645] The TDSO option has been running for some time and, at the firstsynchronization frame after the TDSO was initialized (corresponding tothe action time associated with the Service Connect Message), the31_BIT_PN_NUM, which supplies the 24_BIT_PIN_NUM to drive the TDSO_STATEtransitions (see 0), was initialized and iterated as illustrated in FIG.4 once every frame period after that. Assume the 31_BIT_PN_NUM has acurrent value equal to 0x682dff0c and the current Markov chain is in the“Off” state.

[0646] B.2 Fundamental Channel TDSO process

[0647] Assume that in this stated mode the TDSO is about to transmitframe number 0xab89efad on the Forward Fundamental Traffic Channel(F-FCH) to a mobile station with the least-significant 32 bits of PublicLong-Code Mask (PLCM) equal to 0x9F000307. Since the least significant 9bits of (0xab89efad xor 0x2aaaaaaa) equal 0x107, and the leastsignificant 9 bits of the PLCM are 0x0107, it is time to resynchronizethe F-FCH TDSO process. The pseudo- random number generator associatedwith F-FCH is initialized with F-FRNG (FRNG for the Forward FundamentalChannel) set equal to the 31 least-significant bits of (0xab89efad or0x2aaaaaaa)=0x01234507 as follows (see 0): 01234507 (F-FRNG: startingvalue for the Synchronization Frame) 3288cf26 (F-FRNG: 1st iteration)33d7e1b5 (F-FRNG: 2nd iteration) 22234caa (F-FRNG: 3rd iteration)3b7e3e68 (F-FRNG: 4th iteration)

[0648] After reinitialization, the Forward Fundamental Traffic ChannelTDSO service option would computey_(n)(1)=FRNG/128=0x3b7e3e68/128=0x76fc7c. The least-significant 6 bitsof y_(n)(1), O_(n), is equal to 0x3c, or 60. O_(n) mod B(n) (see Table35) for the values of B(n), for RC3 B(n)=45) determines the byte offsetin the circular buffer (where to begin copying data bits into blocks forthe multiplex sublayer).

[0649] For the synchronization frame, the offset is taken with respectto the first-generated byte in the circular buffer; whereas forsubsequent System Time frames, the byte address next to that of thelast-packed byte from the previous frame serves as the reference. TheTDSO always advances this pointer in the circular buffer according tothe value of O_(n), irrespective of whether any data bits were actuallypassed to the multiplex sublayer during that frame period as determinedby the value of 24_BIT_PN_NUM.

[0650] For the F-FCH, the TDSO generates 45 bytes through random numberiterations. These bytes are put together, starting with the same 24-bitnumber that was used to determine the offset. F-FRNG = 0x3b7e3e68,y_(n)(1) = 0x76fc7c F-FRNG = 0x5d333c5b, y_(n)(2) = 0xba6678 F-FRNG =0x4ebfaa2a, y_(n)(3) = 0x9d7f54 F-FRNG = 0x093cd3ca, y_(n)(4) = 0x1279a7F-FRNG = 0x78747782, y_(n)(5) = 0xf0e8ef F-FRNG = 0x26523596, y_(n)(6) =0x4ca46b F-FRNG = 0x5f3c1e81, y_(n)(7) = 0xbe783d F-FRNG = 0x63f6d7ff,y_(n)(8) = 0xc7edaf F-ERNG = 0x62ded99e, y_(n)(9) = 0xc5bdb3 F-FRNG =0x14a146c8, y_(n)(10) = 0x29428d F-FRNG = 0x682dff0c, y_(n)(11) =0xd05bfe F-FRNG = 0x23c3a243, y_(n)(12) = 0x478744 F-ERNG = 0x00d1ef0d,y_(n)(13) = 0x01a3de F-FRNG = 0x56a53ee6, y_(n)(14) = 0xad4a7d F-FRNG =0x7ac49a7a, y_(n)(15) = 0xf58934

[0651] Each 24-bit number y_(n)(k) is written to the frame buffer inlittle-endian fashion. So 0x76fc7c becomes the byte stream 0x7c 0xfc0x76. The little-endian version of the next 24-bit number, 0xba6678, iswritten immediately after the first number. The circular buffer to beused to generate data blocks for the F-FCH for the next 512 frames isthus organized as follows:

[0652] →7c fc 76 78 66 ba 54 7f 9d a7 79 12 ef e8 f0 6b a4 4c 3d 78 beaf ed c7 b3 bd c5 8d 42 29 fe 5b d0 44 87 47 de a3 01 7d 4a ad 34 89 f5→

[0653] Following the procedure outlined in FIG. 4, the new pseudo-randomnumber generator is as follows, assuming the current value of the PNgenerator for the TDSO state model is 0x682dff0c:

[0654] 31_BIT_PN_NJM=(0x682dff0c * a) mod m=0x23c3a243

[0655] 24_BIT_PN_NUM=31_BIT_PN_NUM>>7=0x478744=4687684

[0656] As the value of 24_BIT_PN_NUM is less than the ON_THRESHOLD, theTDSO_STATE turns to ON and, therefore, TDSO shall pass a Rate 1 frame tothe multiplex sublayer during the current frame period.

[0657] The starting offset for the first frame in the 512-frame segmentis given by O_(n) mod B(n), which, in this case, is 60 mod 45=15.Therefore, the TDSO will generate a Rate 1 (171-bit) frame that can besupplied to the mux sublayer. The frame will be comprised of 21 octetsfrom the circular buffer beginning at the 15th byte offset in thecircular buffer followed by 3 zero bits as shown:

[0658] 6b a4 4c 3d 78 be af ed c7 b3 bd c5 8d 42 29 fe 5b d0 44 8747′000′

[0659] Since this frame is to be carried over the Fundamental Channel,the first 5 bits of the first octet are replaced by ′00000′, theCHANNEL_ID code, and PDU_SEQ_NUM for the FCH as shown in Table 36 andTable 37. Therefore, the final data block passed to the multiplexsublayer is as follows:

[0660] 03 a4 4c 3d 78 be af ed c7 b3 bd c5 8d 42 29 fe 5b d0 44 8747′000′

[0661] For the next TDSO frame, the pseudo-random numbers y_(n)(1) is asfollows: F-FRNG y_(n)(1) 0x0179fe8e 0x02f3fd

[0662] Following the procedure outlined in FIG. 4, the new pseudo-randomnumber generator is as follows:

[0663] 31_BIT_PN_NUM=(0x23c3a243 * a) mod m=0x00dlef0d

[0664] 24_BIT_PN_NUM=31_BIT_PN_NUM>>7=0x1a3de=107486

[0665] As the value of 24_BIT_PN_NUM is less than the ON_THRESHOLD, theTDSO_STATE turns to ON and, therefore, TDSO shall pass a Rate 1 frame tothe multiplex sublayer during the current frame period.

[0666] The 6 least-significant bits of y_(n)(1), O_(n), is 0x3d=61.O_(n) mod 45=16 is used to indicate the byte offset in the circularbuffer. The offset is taken with respect to the byte address next to thelast packed byte from the frame generated in the previous 20 ms period,that is, with respect to the byte 0xde in the buffer.

[0667] The TDSO service option will generate and supply a Rate 1 frameusing 21 octets from the circular buffer followed by 3 zero bits. Thecomplete data block looks like the following:

[0668] 7f 9d a7 79 12 ef e8 f0 6b a4 4c 3d 78 be af ed c7 b3 bd c5 8d′000′

[0669] After replacing the first 5 bits with ′00000′ corresponding tothe data block header for FCH, the data block supplied to the multiplexsublayer, as a data block, is as follows:

[0670] 07 9d a7 79 12 ef e8 f0 6b a4 4c 3d 78 be af ed c7 b3 bd c5 8d′000′

[0671] The byte offset pointer advances to the byte immediately after0x8d, that is, 42 for the next frame.

[0672] A while later , frame number 0xab89f052 is about to be generatedfor the Reverse Fundamental Traffic Channel. Since the least-significantnine bits of (0xab89f052 xor 0x55555555) equal 0x107, and theleast-significant nine bits of the PLCM are 0x0107, it is time toresynchronize the Reverse Traffic Channel TDSO process. The associatedpseudo-random number generator is initialized with F-RRNG set equal tothe 31 least-significant bits of (0xab89f052 xor 0x55555555)=0x7edca507as follows (see 0): 7edca507 (F-RRNG: starting value for theSynchronization Frame) 47d6afa2 (F-RRNG: 1st iteration) 5fa4d986(F-RRNG: 2nd iteration) 3fc51d78 (F-RRNG: 3rd iteration) 2611d1fd(F-RRNG: 4th iteration)

[0673] The Reverse Fundamental Traffic Channel TDSO first computesy_(n)(1)=RRNG/128 =0x2611d1fd/128=0x4c23a3. For the R-FCH, the TDSOgenerates 360 bits (two TDSO frames) through random number iterations.These bytes are put together, starting with the same 24-bit number thatwas used to determine the offset above. F-RRNG = 0x2611d1fd, y_(n)(1) =0x4c23a3 F-RRNG = 0x5bf14c91, y_(n)(2) = 0xb7e299 F-RRNG = 0x3ed9f2bf,y_(n)(3) = 0x7db3e5 F-RRNG = 0x56cff9d5, y_(n)(4) = 0xad9ff3 F-RRNG =0x701b3b79, y_(n)(5) = 0xe03676 F-RRNG = 0x0bddbe6f, y_(n)(6) = 0x17bb7cF-RRNG = 0x0b016f7f, y_(n)(7) = 0x1602de F-RRNG = 0x0b3f007e, y_(n)(8) =0x167e00 F-RRNG = 0x553955f6, y_(n)(9) = 0xaa72ab F-RRNG = 0x273ab530,y_(n)(10) = 0x4e756a F-RRNG = 0x7f4d766e, y_(n)(11) = 0xfe9aec F-RRNG =0x369a710d, y_(n)(12) = 0x6d34e2 F-RRNG = 0x5574287c, y_(n)(13) =0xaae850 F-RRNG = 0x3d0e10b8, y_(n)(14) = 0x7a1c21 F-RRNG = 0x666bbf58,y_(n)(15) = 0xccd77e

[0674] The circular buffer to be used to generate data blocks for theR-FCH for the next 512 frames is thus organized as follows:

[0675] →a3 23 4c 99 e2 b7 e5 b3 7d f3 9f ad 76 36 e0 7c bb 17 de 02 1600 7e 16 ab 72 aa 6a 75 4e ec 9a fe e2 34 6d 50 e8 aa 21 1c 7a 7e d7 cc→

[0676] The 31_BIT_PN_NUM has gone through 164 iterations since thesynchronization time for the Forward Traffic Channel was reached. Thecurrent value of the 32_BIT_PN_NUM=0x4de9620.

[0677] Following the procedure outlined in FIG. 4, the new pseudo-randomnumber generator is as follows, assuming the current value of the PNgenerator for the TDSO state model is 0x0x4de9620:

[0678] 31_BIT_PN_NUM=(0x0x4de9620 * a) mod m=0x3152115f

[0679] 24_BIT_PN_NUM=31_BIT_PN_NUM>>7 =0x62a422=4687684=6464546

[0680] As the value of 24_BIT_PN_NUM is greater than the ON_THRESHOLD,the TDSO_STATE stays in OFF and, therefore, TDSO shall pass a blank datablock (0 bits) to the multiplex sublayer during the current frameperiod.

[0681] The starting offset for the first frame in the 512-frame segmentis given by the 6 least-significant bits of y_(n) (1), O_(n) mod B(n),which in this case is equal to 0x23 mod 45 or 19.

[0682] Even though no frame shall be built in this frame period, thepointer associated with the starting offset for the next frame shall beincremented by 19, that is, the reference byte address for the nextframe in the circular buffer is that of byte 02 in the buffer.

[0683] For the next TDSO frame, the pseudo-random numbers y_(n)(1) is asfollows: F-RRNG y_(n)(1) 0x2bdf5ef0 0x57bebd

[0684] Following the procedure outlined in FIG. 4, the new pseudo-randomnumber generator is as follows:

[0685] 31_BIT_PN_NUM=(0x3152115f * a)mod m=0x2f28d45

[0686] 24_BIT_PN_NUM=31_BIT_PN_NUM>>7=0x5e51a=386330

[0687] As the value of 24_BIT_PN_NUM is less than the ON_THRESHOLD, theTDSO_STATE turns to ON, therefore, it shall pass a Rate 1 frame to themultiplex sublayer during the current frame period.

[0688] The 6 least-significant bits of y_(n)(1), O_(n), is 0x3d=61.O_(n) mod 45=16 is used to indicate the byte offset in the circularbuffer. The offset is taken with respect to the byte address of byte 02in the buffer as stored in the previous frame.

[0689] The TDSO service option will generate and supply a Rate 1 frameusing 21 octets from the circular buffer followed by 3 zero bits. Thepacket derived from the circular buffer thus looks like this:

[0690] 6d 50 e8 aa 21 1c 7a 7e d7 cc a3 23 4c 99 e2 b7 e5 b3 7d f3 ′000′

[0691] However, the first 5 bits are to be replaced by ′00000′ for theFCH. Therefore, the data block supplied to the mux sublayer is:

[0692] 09 50 e8 aa 21 1c 7a 7e d7 cc a3 23 4c 99 e2 b7 e5 b3 7d f3 ′000′

[0693] The reference byte address for the next frame in the circularbuffer is that of byte 9f in the buffer.

[0694] B.3 Supplemental Channel TDSO process

[0695] Assume that in this stated mode the TDSO is about to transmitframe number 0xab89efad on the Forward Supplemental Channel (F-SCH0) toa mobile station with the least-significant 32 bits of PLCM equal to0x9F000307. Since the least-significant nine bits of (0xab89efad xor0x2aaaaaaa) equal 0x107, and the least significant nine bits of the PLCMare 0x0107, it is time to resynchronize the F-SCH0 TDSO process. Thepseudo-random number generator associated with F-SCH0 is initializedwith S-FRNG0 (FRNG for the Forward Supplemental Channel 0) set equal tothe 31 least-significant bits of (0xab89efad xor 0x2aaaaaaa)=0x01234507as follows (see 0): 01234507 (S-FRNG0: starting value for theSynchronization Frame) 3288cf26 (S-FRNG0: 1st iteration) 33d7e1b5(S-FRNG0: 2nd iteration) 22234caa (S-FRNG0: 3rd iteration) 3b7e3e68(S-FRNG0: 4th iteration)

[0696] After reinitialization, the Forward Supplemental Channel TDSOservice option would compute y_(n)(1)=FRNG/128 =0x3b7e3e68/128=0x76fc7c.The least-significant 6 bits of y_(n)(1), on, is equal to 0x3c, or 60.O_(n) mod B(n) (see Table 35) for the values of B(n), for RC3 B(n)=762)determines the byte offset in the circular buffer from where to begincopying data bits into blocks for the multiplex sublayer.

[0697] For the synchronization frame, the offset is taken with respectto the first-generated byte in the circular buffer; whereas forsubsequent System Time frames, the byte address next to that of thelast-packed byte from the previous frame serves as the reference. TheTDSO always advances this pointer in the circular buffer according tothe value of O_(n) mod B(n), irrespective of whether any data bits wereactually passed to the multiplex sublayer during that frame period asdetermined by the value of 24_BIT_PN_NUM.

[0698] For the F-SCH0, the TDSO generates 762 bytes (two full-rate RC3frames) through random number iterations. These bytes are put together,starting with the same 24-bit number that was used to determine theoffset. S-FRNG0 = 0x3b7e3e68, y_(n)(1) = 0x76fc7c S-FRNG0 = 0x5d333c5b,y_(n)(2) = 0xba6678 S-FRNG0 = 0x4ebfaa2a, y_(n)(3) = 0x9d7f54 S-FRNG0 =0x93cd3ca, y_(n)(4) = 0x1279a7 S-FRNG0 = 0x78747782, y_(n)(5) = 0xf0e8efS-FRNG0 = 0x26523596, y_(n)(6) = 0x4ca46b S-FRNG0 = 0x5f3c1e81, y_(n)(7)= 0xbe783d S-FRNG0 = 0x63f6d7ff, y_(n)(8) = 0xc7edaf S-FRNG0 =0x62ded99e, y_(n)(9) = 0xc5bdb3 S-FRNG0 = 0x14a146c8, y_(n)(10) =0x29428d S-FRNG0 = 0x682dff0c, y_(n)(11) = 0xd05bfe S-FRNG0 =0x23c3a243, y_(n)(12) = 0x478744 S-FRNG0 = 0xd1ef0d, y_(n)(13) = 0x1a3deS-FRNG0 = 0x56a53ee6, y_(n)(14) = 0xad4a7d S-FRNG0 = 0x7ac49a7a,y_(n)(15) = 0xf58934 S-FRNG0 = 0x179fe8e, y_(n)(16) = 0x2f3fd S-FRNG0 =0x70371d63, y_(n)(17) = 0xe06e3a S-FRNG0 = 0x326a8823, y_(n)(18) =0x64d510 S-FRNG0 = 0x700fcbb0, y_(n)(19) = 0xe01f97 S-FRNG0 =0x1d05c94a, y_(n)(20) = 0x3a0b92 S-FRNG0 = 0x66e22828, y_(n)(21) =0xcdc450 S-FRNG0 = 0x9ba8edd, y_(n)(22) = 0x13751d S-FRNG0 = 0x36f95428,y_(n)(23) = 0x6df2a8 S-FRNG0 = 0x2b042a4a, y_(n)(24) = 0x560854 S-FRNG0= 0x1e747656, y_(n)(25) = 0x3ce8ec S-FRNG0 = 0x700517b8, y_(n)(26) =0xe00a2f S-FRNG0 = 0x5e586a7c, y_(n)(27) = 0xbcb0d4 S-FRNG0 =0x7eb72347, y_(n)(28) = 0xfd6e46 S-FRNG0 = 0x296d4b4f, y_(n)(29) =0x52da96 S-FRNG0 = 0x466b44c8, y_(n)(30) = 0x8cd689 S-FRNG0 =0x2c70ca96, y_(n)(31) = 0x58e195 S-FRNG0 = 0x210454a5, y_(n)(32) =0x4208a9 S-FRNG0 = 0x23512d92, y_(n)(33) = 0x46a25b S-FRNG0 =0x2686de5b, y_(n)(34) = 0x4d0dbc S-FRNG0 = 0x60703c1f, y_(n)(35) =0xc0e078 S-FRNG0 = 0x687b48af, y_(n)(36) = 0xd0f691 S-FRNG0 =0x75e10ebf, y_(n)(37) = 0xebc21d S-FRNG0 = 0xa8f5a0f, y_(n)(38) =0x151eb4 S-FRNG0 = 0x49619433, y_(n)(39) = 0x92c328 S-FRNG0 =0x2548c5e8, y_(n)(40) = 0x4a918b S-FRNG0 = 0x4cb91577, y_(n)(41) =0x99722a S-FRNG0 = 0xb305efb, y_(n)(42) = 0x1660bd S-FRNG0 = 0x14abb67a,y_(n)(43) = 0x29576c S-FRNG0 = 0x15590e30, y_(n)(44) = 0x2ab21c S-FRNG0= 0x9b27c43, y_(n)(45) = 0x1364f8 S-FRNG0 = 0x24fc17ae, y_(n)(46) =0x49f82f S-FRNG0 = 0x2276b37a, y_(n)(47) = 0x44ed66 S-FRNG0 =0x1f012043, y_(n)(48) = 0x3e0240 S-FRNG0 = 0x2ed1e9c, y_(n)(49) =0x5da3d S-FRNG0 = 0x1d749544, y_(n)(50) = 0x3ae92a S-FRNG0 = 0x50f3b277,y_(n)(51) = 0xa1e764 S-FRNG0 = 0x2f49cc26, y_(n)(52) = 0x5e9398 S-FRNG0= 0x15f9eb0b, y_(n)(53) = 0x2bf3d6 S-FRNG0 = 0x4ab62a72, y_(n)(54) =0x956c54 S-FRNG0 = 0x7d9cc8af, y_(n)(55) = 0xfb3991 S-FRNG0 =0x403b9996, y_(n)(56) = 0x807733 S-FRNG0 = 0x8e067cc, y_(n)(57) =0x11c0cf S-FRNG0 = 0x44be86a1, y_(n)(58) = 0x897d0d S-FRNG0 =0x3878d749, y_(n)(59) = 0x70f1ae S-FRNG0 = 0x57e1696, y_(n)(60) =0xafc2d S-FRNG0 = 0x18fcd4ab, y_(n)(61) = 0x31f9a9 S-FRNG0 = 0x7eee335d,y_(n)(62) = 0xfddc66 S-FRNG0 = 0x486e5fc5, y_(n)(63) = 0x90dcbf S-FRNG0= 0x4651a3a9, y_(n)(64) = 0x8ca347 S-FRNG0 = 0x19cfd050, y_(n)(65) =0x339fa0 S-FRNG0 = 0x1a75416d, y_(n)(66) = 0x34ea82 S-FRNG0 = 0x81a68ad,y_(n)(67) = 0x1034d1 S-FRNG0 = 0x7dce3a02, y_(n)(68) = 0xfb9c74 S-FRNG0= 0x6e4299d4, y_(n)(69) = 0xdc8533 S-FRNG0 = 0x568165d9, y_(n)(70) =0xad02cb S-FRNG0 = 0x4945b5ed, y_(n)(71) = 0x928b6b S-FRNG0 =0x7fab002f, y_(n)(72) = 0xff5600 S-FRNG0 = 0x33994f24, y_(n)(73) =0x67329e S-FRNG0 = 0x161adef3, y_(n)(74) = 0x2c35bd S-FRNG0 =0x3e232edb, y_(n)(75) = 0x7c465d S-FRNG0 = 0x77d94bbb, y_(n)(76) =0xefb297 S-FRNG0 = 0x5afb1f75, y_(n)(77) = 0xb5f63e S-FRNG0 =0x1cce68fd, y_(n)(78) = 0x399cd1 S-FRNG0 = 0x334ec8d1, y_(n)(79) =0x669d91 S-FRNG0 = 0x79622ba7, y_(n)(80) = 0xf2c457 S-FRNG0 =0x1c201f33, y_(n)(81) = 0x38403e S-FRNG0 = 0xe05bb2, y_(n)(82) = 0x1c0b7S-FRNG0 = 0x9a40391, y_(n)(83) = 0x134807 S-FRNG0 = 0x6ee62988,y_(n)(84) = 0xddcc53 S-FRNG0 = 0x48b0d899, y_(n)(85) = 0x9161b1 S-FRNG0= 0x525c4a171 y_(n)(86) = 0xa4b894 S-FRNG0 = 0x2904563f, y_(n)(87) =0x5208ac S-FRNG0 = 0x5bba5722, y_(n)(88) = 0xb774ae S-FRNG0 =0x26aea83a, y_(n)(89) = 0x4d5d50 S-FRNG0 = 0x14a68bad, y_(n)(90) =0x294d17 S-FRNG0 = 0x421c1572, y_(n)(91) = 0x84382a S-FRNG0 =0x41c41146, y_(n)(92) = 0x838822 S-FRNG0 = 0x2f4a2c65, y_(n)(93) =0x5e9458 S-FRNG0 = 0x2ea8b324, y_(n)(94) = 0x5d5166 S-FRNG0 =0x4589186a, y_(n)(95) = 0x8b1230 S-FRNG0 = 0x2ba1fad0, y_(n)(96) =0x5743f5 S-FRNG0 = 0x17598411, y_(n)(97) = 0x2eb308 S-FRNG0 =0x75ed8410, y_(n)(98) = 0xebdb08 S-FRNG0 = 0x3c7972ec, y_(n)(99) =0x78f2e5 S-FRNG0 = 0x496802f8, y_(n)(100) = 0x92d005 S-FRNG0 =0x4b9b0d6e, y_(n)(101) = 0x97361a S-FRNG0 = 0x308ed789, y_(n)(102) =0x611daf S-FRNG0 = 0x71e87c46, y_(n)(103) = 0xe3d0f8 S-FRNG0 =0x56371216, y_(n)(104) = 0xac6e24 S-FRNG0 = 0x39848e92, y_(n)(105) =0x73091d S-FRNG0 = 0x2dac30be, y_(n)(106) = 0x5b5861 S-FRNG0 =0x3b4215f, y_(n)(107) = 0x76842 S-FRNG0 = 0x26fae5df, y_(n)(108) =0x4df5cb S-FRNG0 = 0x2209a777, y_(n)(109) = 0x44134e S-FRNG0 =0x27d18716, y_(n)(110) = 0x4fa30e S-FRNG0 = 0x2cfbc9c6, y_(n)(111) =0x59f793 S-FRNG0 = 0x467bfd3c1 y_(n)(112) = 0x8cf7fa S-FRNG0 =0x762e924a, y_(n)(113) = 0xec5d24 S-FRNG0 = 0x6b8674e3, y_(n)(114) =0xd70ce9 S-FRNG0 = 0x48641a3b, y_(n)(115) = 0x90c834 S-FRNG0 =0x23f63c9e, y_(n)(116) = 0x47ec79 S-FRNG0 = 0x7b05bb83, y_(n)(117) =0xf60b77 S-FRNG0 = 0x3559d48e, y_(n)(118) = 0x6ab3a9 S-FRNG0 =0x1c91d1ff, y_(n)(119) = 0x3923a3 S-FRNG0 = 0x2971cb00, y_(n)(120) =0x52e396 S-FRNG0 = 0x6dc68241, y_(n)(121) = 0xdb8d04 S-FRNG0 =0x391b1b5, y_(n)(122) = 0x72363 S-FRNG0 = 0x5229e3e7, y_(n)(123) =0xa453c7 S-FRNG0 = 0x3c317cd5, y_(n)(124) = 0x7862f9 S-FRNG0 =0x54faa2d2, y_(n)(125) = 0xa9f545 S-FRNG0 = 0x12d7b494, y_(n)(126) =0x25af69 S-FRNG0 = 0xf906a36, y_(n)(127) = 0x1f20d4 S-FRNG0 =0x522d0735, y_(n)(128) = 0xa45a0e S-FRNG0 = 0xa3452b9, y_(n)(129) =0x1468a5 S-FRNG0 = 0x7122f4ea, y_(n)(130) = 0xe245e9 S-FRNG0 =0x2dfd68ad, y_(n)(131) = 0x5bfad1 S-FRNG0 = 0x57e34d71, y_(n)(132) =0xafc69a S-FRNG0 = 0xbf162cb, y_(n)(133) = 0x17e2c5 S-FRNG0 =0x148d038d, y_(n)(134) = 0x291a07 S-FRNG0 = 0x35e42885, y_(n)(135) =0x6bc851 S-FRNG0 = 0x16204f67, y_(n)(136) = 0x2c409e S-FRNG0 =0x233cfe8a, y_(n)(137) = 0x4679fd S-FRNG0 = 0x796b2818, y_(n)(138) =0xf2d650 S-FRNG0 = 0x6a157dee, y_(n)(139) = 0xd42afb S-FRNG0 =0x28fecaab, y_(n)(140) = 0x51fd95 S-FRNG0 = 0x6fabb593, y_(n)(141) =0xdf576b S-FRNG0 = 0x721dff2b, y_(n)(142) = 0xe43bfe S-FRNG0 =0xf5b9a95, y_(n)(143) = 0x1eb735 S-FRNG0 = 0x4701b413, y_(n)(144) =0x8e0368 S-FRNG0 = 0x40d56fd0, y_(n)(145) = 0x81aadf S-FRNG0 =0x7c9fe1f0, y_(n)(146) = 0xf93fc3 S-FRNG0 = 0x64aa937b, y_(n)(147) =0xc95526 S-FRNG0 = 0x7ab8a3de, y_(n)(148) = 0xf57147 S-FRNG0 =0x700e82c3, y_(n)(149) = 0xe01d05 S-FRNG0 = 0x48ab09ae, y_(n)(150) =0x915613 S-FRNG0 = 0x5508a3c7, y_(n)(151) = 0xaa1147 S-FRNG0 =0x2a38896e, y_(n)(152) = 0x547112 S-FRNG0 = 0x65c6aa69, y_(n)(153) =0xcb8d54 S-FRNG0 = 0x55de07b2, y_(n)(154) = 0xabbc0f S-FRNG0 =0x63cb6328, y_(n)(155) = 0xc796c6 S-FRNG0 = 0x3ddb0a47, y_(n)(156) =0x7bb614 S-FRNG0 = 0x777fdb0a, y_(n)(157) = 0xeeffb6 S-FRNG0 =0x6b05aad0, y_(n)(158) = 0xd60b55 S-FRNG0 = 0x41117494, y_(n)(159) =0x8222e9 S-FRNG0 = 0x60fcc1eb, y_(n)(160) = 0xc1f983 S-FRNG0 =0x721f5d0b, y_(n)(161) = 0xe43eba S-FRNG0 = 0x6915b7b5, y_(n)(162) =0xd22b6f S-FRNG0 = 0x10d001f9, y_(n)(163) = 0x21a003 S-FRNG0 =0x48318b0e, y_(n)(164) = 0x906316 S-FRNG0 = 0x2ca06929, y_(n)(165) =0x5940d2 S-FRNG0 = 0x575819a2, y_(n)(166) = 0xaeb033 S-FRNG0 =0x58fb077a, y_(n)(167) = 0xb1f60e S-FRNG0 = 0x48a80839, y_(n)(168) =0x915010 S-FRNG0 = 0xfb3fb73, y_(n)(169) = 0x1f67f6 S-FRNG0 =0x71414312, y_(n)(170) = 0xe28286 S-FRNG0 = 0x739a8cd4, y_(n)(171) =0xe73519 S-FRNG0 = 0x2793ed97, y_(n)(172) = 0x4f27db S-FRNG0 =0x60d368cd, y_(n)(173) = 0xc1a6d1 S-FRNG0 = 0x57859c64, y_(n)(174) =0xaf0b38 S-FRNG0 = 0x4de9620, y_(n)(175) = 0x9bd2c S-FRNG0 = 0x3152115f,y_(n)(176) = 0x62a422 S-FRNG0 = 0x2f28d45, y_(n)(177) = 0x5e51a S-FRNG0= 0x218ae86, y_(n)(178) = 0x4315d S-FRNG0 = 0x2269e07d, y_(n)(179) =0x44d3c0 S-FRNG0 = 0x55114031, y_(n)(180) = 0xaa2280 S-FRNG0 =0x5f8d7c98, y_(n)(181) = 0xbf1af9 S-FRNG0 = 0x41ef102a, y_(n)(182) =0x83de20 S-FRNG0 = 0x360e5737, y_(n)(183) = 0x6c1cae S-FRNG0 =0x677ff79a, y_(n)(184) = 0xceffef S-FRNG0 = 0x258d48c, y_(n)(185) =0x4b1a9 S-FRNG0 = 0x15ea3488, y_(n)(186) = 0x2bd469 S-FRNG0 =0x431ed7f5, y_(n)(187) = 0x863daf S-FRNG0 = 0x1df43840, y_(n)(188) =0x3be870 S-FRNG0 = 0xc99011d, y_(n)(189) = 0x193202 S-FRNG0 =0x11181d61, y_(n)(190) = 0x22303a S-FRNG0 = 0x4630d40b, y_(n)(191) =0x8c61a8 S-FRNG0 = 0x2fb1422d, y_(n)(192) = 0x5f6284 S-FRNG0 =0x1e6fb0d1, y_(n)(193) = 0x3cdf61 S-FRNG0 = 0x36c178f3, y_(n)(194) =0x6d82f1 S-FRNG0 = 0x57ebb59a, y_(n)(195) = 0xafd76b S-FRNG0 =0x33dfbe8e, y_(n)(196) = 0x67bf7d S-FRNG0 = 0x2657773d, y_(n)(197) =0x4caeee S-FRNG0 = 0x38555975, y_(n)(198) = 0x70aab2 S-FRNG0 =0x6b642d37, y_(n)(199) = 0xd6c85a S-FRNG0 = 0x7dd4acf5, y_(n)(200) =0xfba959 S-FRNG0 = 0x15a7495d, y_(n)(201) = 0x2b4e92 S-FRNG0 =0x19c183c6, y_(n)(202) = 0x338307 S-FRNG0 = 0x6fb2495f, y_(n)(203) =0xdf6492 S-FRNG0 = 0x21ef3543, y_(n)(204) = 0x43de6a S-FRNG0 =0x5f91d31c, y_(n)(205) = 0xbf23a6 S-FRNG0 = 0x5ebb0448, y_(n)(206) =0xbd7608 S-FRNG0 = 0x4816438e, y_(n)(207) = 0x902c87 S-FRNG0 =0x2dad449b, y_(n)(208) = 0x5b5a89 S-FRNG0 = 0x4a73338a, y_(n)(209) =0x94e667 S-FRNG0 = 0x513ccf35, y_(n)(210) = 0xa2799e S-FRNG0 =0x6f47ca3d, y_(n)(211) = 0xde8f94 S-FRNG0 = 0x522ea3de, y_(n)(212) =0xa45d47 S-FRNG0 = 0x74086df8, y_(n)(213) = 0xe810db S-FRNG0 =0x556bf04b, y_(n)(214) = 0xaac17e0 S-FRNG0 = 0x216cf7bd, y_(n)(215) =0x42d9ef S-FRNG0 = 0x78fcaa6f, y_(n)(216) = 0xf1f954 S-FRNG0 =0x14199b77, y_(n)(217) = 0x283336 S-FRNG0 = 0x1d2dabf0, y_(n)(218) =0x3a5b57 S-FRNG0 = 0x21732887, y_(n)(219) = 0x42e651 S-FRNG0 =0xf69c839, y_(n)(220) = 0x1ed390 S-FRNG0 = 0x69d81e16, y_(n)(221) =0xd3b03c S-FRNG0 = 0x6b9f6ca3, y_(n)(222) = 0xd73ed9 S-FRNG0 =0x2f957888, y_(n)(223) = 0x5f2af1 S-FRNG0 = 0x7e1c411f, y_(n)(224) =0xfc3882 S-FRNG0 = 0x70f79ae7, y_(n)(225) = 0xe1ef35 S-FRNG0 =0xfdaeda2, y_(n)(226) = 0x1fb5db S-FRNG0 = 0x6e272ecf, y_(n)(227) =0xdc4e5d S-FRNG0 = 0x4e725088, y_(n)(228) = 0x9ce4a1 S-FRNG0 =0x330538f4, y_(n)(229) = 0x660a71 S-FRNG0 = 0x1bde3557, y_(n)(230) =0x37bc6a S-FRNG0 = 0x197ff10c, y_(n)(231) = 0x32ffe2 S-FRNG0 =0x1eaa57e8, y_(n)(232) = 0x3d54af S-FRNG0 = 0x41715012, y_(n)(233) =0x82e2a0 S-FRNG0 = 0x763fef4e, y_(n)(234) = 0xec7fde S-FRNG0 =0x5f782688, y_(n)(235) = 0xbef04d S-FRNG0 = 0x4929dbaf, y_(n)(236) =0x9253b7 S-FRNG0 = 0x5b15e3af, y_(n)(237) = 0xb62bc7 S-FRNG0 =0x7a1724e0, y_(n)(238) = 0xf42e49 S-FRNG0 = 0x5762cbf, y_(n)(239) =0xaec59 S-FRNG0 = 0x1173b266, y_(n)(240) = 0x22e764 S-FRNG0 =0x42c54f7d, y_(n)(241) = 0x858a9e S-FRNG0 = 0x27e5b9ca, y_(n)(242) =0x4fcb73 S-FRNG0 = 0x5b08913c, y_(n)(243) = 0xb61122 S-FRNG0 =0xf7728d5, y_(n)(244) = 0x1eee51 S-FRNG0 = 0x5819bfe1, y_(n)(245) =0xb0337f S-FRNG0 = 0x28479f7, y_(n)(246) = 0x508f3 S-FRNG0 = 0x4763486b,y_(n)(247) = 0x8ec690 S-FRNG0 = 0x47278d6a, y_(n)(248) = 0x8e4f1aS-FRNG0 = 0x75b54ea4, y_(n)(249) = 0xeb6a9d S-FRNG0 = 0x523e2d5b,y_(n)(250) = 0xa47c5a S-FRNG0 = 0x7013db8b, y_(n)(251) = 0xe027b7S-FRNG0 = 0x27b2bc29, y_(n)(252) = 0x4f6578 S-FRNG0 = 0x475f3c1b,y_(n)(253) = 0x8ebe78 S-FRNG0 = 0x3d633538, y_(n)(254) = 0x7ac66a

[0699] Each 24-bit number y_(n)(k) is written to the frame buffer inlittle-endian fashion. So 0x76fc7c turns into the byte stream 0x7c 0xfc0x76. The little-endian version of the next 24-bit number, 0xba6678, iswritten immediately after the first number.

[0700] The circular buffer to be used to generate data block(s) for theF-SCH for the next 512 frames is thus organized as follows:

[0701] →7c fc 76 78 66 ba 54 7f 9d a7 79 12 ef e8 f0 6b a4 4c 3d 78 beaf ed c7 b3 bd c5 8d 42 29 fe 5b d0 44 87 47 de a3 01 7d 4a ad 34 89 f5fd f3 02 3a 6e e0 10 d5 64 97 1f e0 92 0b 3a 50 c4 cd 1d 75 13 a8 f2 6d54 08 56 ec e8 3c 2f 0a e0 d4 b0 bc 46 6e fd 96 da 52 89 d6 8c 95 e1 58a9 08 42 5b a2 46 bc 0d 4d 78 e0 c0 91 f6 d0 1d c2 eb b4 1e 15 28 c3 928b 91 4a 2a 72 99 bd 60 16 6c 57 29 1c b2 2a f8 64 13 2f f8 49 66 ed 4440 02 3e 3d da 05 2a e9 3a 64 e7 al 98 93 5e d6 f3 2b 54 6c 95 91 39 fb33 77 80 cf c0 11 0d 7d 89 ae f1 70 2d fc 0a a9 f9 31 66 dc fd bf dc 9047 a3 8c a0 9f 33 82 ea 34 d1 34 10 74 9c fb 33 85 dc cb 02 ad 6b 8b 9200 56 ff 9e 32 67 bd 35 2c 5d 46 7c 97 b2 ef 3e f6 b5 d1 9c 39 91 9d 6657 c4 f2 3e 40 38 b7 c0 01 07 48 13 53 cc dd b1 61 91 94 b8 a4 ac 08 52ae 74 b7 50 5d 4d 17 4d 29 2a 38 84 22 88 83 58 94 5e 66 51 5d 30 12 8bf5 43 57 08 b3 2e 08 db eb e5 f2 78 05 d0 92 1a 36 97 af 1d 61 f8 d0 e324 6e ac 1d 09 73 61 58 5b 42 68 07 cb f5 4d 4e 13 44 0e a3 4f 93 f7 59fa f7 8c 24 5d ec e9 0c d7 34 c8 90 79 ec 47 77 0b f6 a9 b3 6a a3 23 3996 e3 52 04 8d db 63 23 07 c7 53 a4 f9 62 78 45 f5 a9 69 af 25 d4 20 1f0e 5a a4 a5 68 14 e9 45 e2 d1 fa 5b 9a c6 af c5 e2 17 07 1a 29 51 c8 6b9e 40 2c fd 79 46 50 d6 f2 fb 2a d4 95 fd 51 6b 57 df fe 3b e4 35 b7 1e68 03 8e df aa 81 c3 3f f9 26 55 c9 47 71 f5 05 1d e0 13 56 9147 11 aa12 71 54 54 8d cb 0f bc ab c6 96 c7 14 b6 7b b6 ff ee 55 0b d6 e9 22 8283 f9 cl ba 3e e4 6f 2b d2 03 a0 21 16 63 90 d2 40 59 33 b0 ae 0e f6 b110 50 91 f6 67 1f 86 82 e2 19 35 e7 db 27 4f d1 a6 c1 38 0b af 2c bd 0922 a4 62 1a e5 05 5d 31 04 c0 d3 44 80 22 aa f9 1a bf 20 de 83 ae 1c 6cef ff ce a9 b1 04 69 d4 2b af 3d 86 70 e8 3b 02 32 19 3a 30 22 a8 61 8c84 62 5f 61 df 3c f1 82 6d 6b d7 af 7d bf 67 ee ae 4c b2 aa 70 5a c8 d659 a9 fb 92 4e 2b 07 83 33 92 64 df 6a de 43 a6 23 bf 08 76 bd 87 2c 9089 5a 5b 67 e6 94 9e 79 a2 94 8f de 47 5d a4 db 10 e8 e0 d7 aa ef d9 4254 f9 f1 36 33 28 57 5b 3a 51 e6 42 90 d3 1e 3c b0 d3 d9 3e d7 fl 2a 5f82 38 fc 35 ef e1 db b5 1f 5d 4e dc a1 e4 9c 71 0a 66 6a bc 37 e2 ff 32af 54 3d a0 e2 82 de 7f ec 4d f0 be b7 53 92 c7 2b b6 49 2e f4 59 ec 0a64 e7 22 9e 8a 85 73 cb 4f 22 11 b6 51 ee 1e 7f 33 b0 f3 08 05 90 c6 8e1a 4f 8e 9d 6a eb 5a 7c a4 b7 27 e0 78 65 4f 78 be 8e 6a c6 7a→

[0702] Following the procedure outlined in FIG. 4, the new pseudo-randomnumber generator is as follows:

[0703] 31_BIT_PN_NUM=(0x682dff0c * a) mod m=0x23c3a243

[0704] 24_BIT_PN_NUM=31_BIT_PN_NUM>>7 =0x478744=4687684

[0705] As the value of 24_BIT_PN_NUM is less than the ON_THRESHOLD, theTDSO_STATE turns to ON and, therefore, TDSO shall pass two Rate 1 frameto the multiplex sublayer during the current frame period.

[0706] The starting offset for the first frame in the 512 frame segmentis given by O_(n) mod B(n), which in this case is 60 mod 762=60.Therefore, the TDSO will generate two Rate 1 (170-bit) date blocks thatare supplied to the multiplex sublayer. Each data block is comprised of21 octets from the circular buffer beginning at the 60th byte offset inthe circular buffer followed by 2 zero bits as shown:

[0707] 50 c4 cd 1d 75 13 a8 f2 6d 54 08 56 ec e8 3c 2f 0a e0 d4 b0 bc′00′46 6e fd 96 da 52 89 d6 8c 95 el 58 a9 08 42 5b a2 46 bc 0d 4d ′00′

[0708] The first 5 bits of each generated PDU, however, will be maskedby 2 bits representing the CHANNEL_ID, that is, 10 for F-SCH0 followedby 3 bits to designate the PDU sequence number within the physical layerSDU (′000′ for first data block and ′001′ for the second). Therefore,the two data blocks that are passed to the multiplex sublayer look likethe following:

[0709] PDU1->80 c4 cd 1d 75 13 a8 f2 6d 54 08 56 ec e8 3c 2f 0a e0 d4 b0bc ′00′

[0710] PDU2->8e 6e fd 96 da 52 89 d6 8c 95 e1 58 a9 08 42 5b a2 46 bc 0d4d ′00′

[0711] For the next frame, however, the byte offset pointer advances tothe byte immediately after 4d, that is, 78.

[0712] Using the TDSO

[0713] C.1 Introduction

[0714] This annex outlines the procedure for conducting a TDSO test anda method for computing frame error rates.

[0715] C.2 Conducting a TDSO test

[0716] A TDSO test may be conducted at a base station using thefollowing procedures:

[0717] 1. Start a TDSO call (or clear the counters of an existing call).

[0718] To conduct a TDSO call with a random data source, send a ServiceOption Control Message control directive with DATA_SOURCE field set to′001′ and the CLEAR_COUNTERS field set to ′1′ for the particularphysical channel.

[0719] Wait for the test interval to elapse.

[0720] Direct the mobile station to make a copy of the TDSO counters.

[0721] Wait for the forward synchronization and reverse synchronizationframe after the action time to occur.

[0722] Retrieve the values of the copied counters from the mobilestation and compute the FERs.

[0723] A call is started by negotiating the TDSO (see 0) andinitializing and connecting the service option. The service optioncounters are cleared at initialization, or could be cleared explicitlyby the base station by sending a control directive while a TDSO call isin progress.

[0724] The duration of a test should correspond to an integral number ofsegments (see 0). The mobile station's processing of the controldirective (see 0) enforces this test duration.

[0725] The base station sends a Service Option Control Message directingthe mobile station to copy the received and transmitted TDSO counters tobuffers at the next Forward and Reverse Traffic Channel synchronizationframes. This provides a synchronized snapshot of all the TDSO countersfor accurate calculations of FERs.

[0726] The base station sends Service Option Control Messages to requestcounter values to be retrieved from the copied buffer. These countervalues are used in frame-error rate and bit-error rate calculations.

[0727] C.3 Computation of FERs

[0728] C.3.1 FER computation on the FCH and DCCH

[0729] The FER on the Forward Fundicated Traffic Channel is given by thefollowing calculation:

[0730] FER_(Rate 1) (Forward)=1-(TDSO_E1_R1_(m)+TDSO_EN_RN_(m))/(TDSO_E1_T1_(b)+TDSO_EB_TB_(b))

[0731] where counters in the mobile station are denoted by a subscriptm, and counters in the base station are denoted by a subscript b.

[0732] The FER of the Reverse Fundicated Traffic Channel is given by thefollowing calculation:

[0733] FER_(Rate 1) (Reverse)=1-(TDSO_E1_R1_(b)+TDSO_EN_RN_(b))/(TDSO_E1_T1__(m)+TDSO_EB_TB_(m))

[0734] where counters in the mobile station are denoted by a subscriptm, and counters in the base station are denoted by a subscript b.

[0735] The number of dim-and-burst frames and the number ofblank-and-burst frames are not used in the FER calculations describedabove.

[0736] The values of the base station transmit counter TDSO_E1_T1_(b),TDSO_EB_TB_(b) can be estimated by summing the values of thecorresponding mobile station counters for received frames as follows:

[0737]TDSO_E1_T1_(b)≈TDSO_E1R1_(m)+TDSO_E1_RO_(m)+TDSO_1_RFL_(m)+TDSO_E1_RE_(m)TDSO_E1_RERR_(m)TDSO_EB_JTB_(b)≈TDSO_EN_RN_(m)+TDSO_EN_RO_(m)

[0738] The values of the mobile station transmit counter TDSO_E1_T1_(m),TDSO_EB_TB_(m) can be estimated at the base station by summing thevalues of the corresponding base station counters for received frames asfollows:

[0739]TDSO_E1_T1_(m)≈TDSO_E1_R1_(b)+TDSO_E1_RO_(b)+TDSO_E1RFL_(b)+TDSO_E1RE_(b)+TDSO_E1_RERR_(b)TDSO_EB_TB_(m)≈TDSO_EN_RN_(b)+TDSO_EN_RO_(b)

[0740] C.3.2 FER computation on the SCH

[0741] The FER of Nx9.6 or Nx14.4 frames on the Forward SupplementalChannel is given by the following calculation:

[0742] FER_(Rate Nx9.6 Or Nx14.4) (Forward)=1 -(TDSO_ENx_RNx_(m)+TDSO_EB_RB_(m)) / (TDSO_ENx_TNx_(b)+TDSO_EB_TB_(b))

[0743] where counters in the mobile station are denoted by a subscriptm, and counters in the base station are denoted by a subscript b.

[0744] The FERs of Nx9.6 or Nx14.4 frames on the Reverse FundicatedTraffic Channel are given by the following calculation:

[0745] FER_(Rate Nx9.6 or Nx14.4) (Reverse)=1 -(TDSO_ENx_RNX_(b)+TDSO_EB_RBb)/(TDSO_ENx_TNx_(m)+TDSO_EB_TB_(m))

[0746] where counters in the mobile station are denoted by a subscriptm, and counters in the base station are denoted by a subscript b.

[0747] The values of the base station transmit counter TDSO_ENx_TNx_(b),TDSO_EB_TB_(b) can be estimated by summing the values of thecorresponding mobile station counters for received frames as follows:

[0748]TDSO_ENx_TNx_(b)≈TDSO_ENx_RNx_(m)+TDSO_ENx_RE_(m)+TDSO_ENx_RERR_(m),TDSO_EB_TB_(b)≈TDSO_EB_RB_(m)+TDSO_EB_RO_(m)

[0749] The values of the mobile station transmit counterTDSO_ENx_TNx_(m), TDSO_EB_TB_(m) can be estimated at the base station bysumming the values of the corresponding base station counters forreceived frames as follows:

[0750]TDSO_ENx_TNx_(m)≈TDSO_ENx_RNx_(b)+TDSO_ENx_RE_(b)+TDSO_ENx_RERR_(b),TDSO_EB_TB_(m)≈TDSO_EB_RB_(b)+TDSO_EB_RO_(b)

[0751] C.4 PER computation on SCH

[0752] The PER of Rate 1 a, Rate 1 b, Rate 2, and Rate 3 frames on theForward Supplemental Traffic Channel is given by the followingcalculation:

[0753] PER_(Rate 1a) (Forward)=1 - TDSO_Ela_R1am/TDSO_E1a_T1a_(b)

[0754] PER_(Rate 1b) (Forward)=1 - TDSO_E1b_R1b_(m)/TDSO_E1b_T1b_(b)

[0755] PER_(Rate 2) (Forward)=1 - TDSO_E2_R2_(m)/TDSO_E2_T2_(b)

[0756] PER_(Rate 3) (Forward)=1 - TDSO_E3_R3m/TDSO_E3_T3_(b)

[0757] where counters in the mobile station are denoted by a subscriptm, and counters in the base station are denoted by a subscript b.

[0758] The PER of Rate 1 a, Rate 1 b, Rate 2, and Rate 3 frames on theReverse Supplemental Traffic Channel is given by the followingcalculation:

[0759] PER_(Rate 1a) (Reverse)=1 - TDSO_E1a_R1a_(b)/TDSO_E1a_T1a_(m)

[0760] PER_(Rate 1b) (Reverse)=1 - TDSO_E1b_R1b_(b)/TDSO_E1b_T1b_(m)

[0761] PER_(Rate 2) (Reverse)=1 - TDSO_E2_R2_(b)/TDSO_E2_T2_(m)

[0762] PER_(Rate 3) (Reverse)=1 - TDSO_E3_R3_(b)/TDSO_E2_T2_(m)

[0763] where counters in the mobile station are denoted by a subscriptm, and counters in the base station are denoted by a subscript b.

[0764] The values of the base station transmit countersTDSO_Ela_T1a_(b), TDSO_E1b_T1b_(b), TDSO_E2_T2_(b), and TDSO_E3_T3_(b)can be calculated by summing the values of the corresponding mobilestation counters for received frames as follows:

[0765]TDSO_E1a_T1a_(b)=TDSO_E1a_R1a_(m)+TDSO_E1a_RERR_(m)+TDSO_E1a_RE_(m),TDSO_E1b_T1b_(b)=TDSO_E1b_R1b_(m)+TDSO_E1b_RERR_(m)+TDSO_E1b_RE_(m),TDSO_E2_T2_(b)=TDSO_E2_R2_(m)+TDSO_E2_RERR_(m)+TDSO_E2_RE_(m),TDSO_E3_T3_(b)=TDSO_E3_R3_(m)+TDSO_E3_RERR_(m)+TDSO_E3_RE_(m)

[0766] The values of the mobile station transmit countersTDSO_E1a_T1a_(m), TDSO_E1b_T1b_(m), TDSO_E2_T2_(m), and TDSO_E3_T3_(m)can be calculated by summing the values of the corresponding basestation counters for received frames as follows:

[0767]TDSO_E1a_T1a_(m)=TDSO_E1a_R1a_(b)+TDSO_E1a_RERR_(b)+TDSO_E1a_RE_(b),

[0768]TDSO_E1b_T1b_(m)=TDSO_E1b_R1b_(b)+TDSO_E1b_RERR_(b)+TDSO_E1b_RE_(b),

[0769] TDSO_E2_T2_(m)=TDSO_E2_R2_(b)+TDSO_E2_RERR_(b)+TDSO_E2_RE_(b),

[0770] TDSO_E3_T3_(m)=TDSO_E3_R3_(b)+TDSO_E3_RERR_(b)+TDSO_E3_RE_(b)

[0771] C.5 FER computation on the FCH and DCCH with 5 ms frame length

[0772] The FER on the Forward Fundicated Traffic Channel is given by thefollowing calculation:

[0773] Let R_(m) be the number of good 5 ms frames received in themobile station and T_(b) be the total number of 5 ms frames transmittedby the base station during the test period, then

[0774] FER_(Rate 1) (Forward)=1 - (R_(m)/T_(b))

[0775] where counters in the mobile station are denoted by a subscriptm, and counters in the base station are denoted by a subscript b.

[0776] The FER on the Reverse Fundicated Traffic Channel is given by thefollowing calculation:

[0777] Let R_(b) be the number of good 5 ms frames received in the basestation and T_(m) be the total number of 5 ms frames transmitted by themobile station during the test period, then

[0778] FER_(Rate 1) (Reverse)=1 - (R_(b)/T_(m))

[0779] where counters in the mobile station are denoted by a subscriptm, and counters in the base station are denoted by a subscript b.

[0780] Both R_(m) and T_(m) can be derived from the values of the mobilestation counters (e.g., MUX1_FOR_FCH_5_ms) retrieved in the 5 ms FrameReceived Counters Response and 5 ms Frame Transmitted Counters Response,respectively. For example, for a 5 ms DCCH using Multiplex Option 0x01,R_(m) can be calculated as the difference of the values ofTDSO_MUX1_5ms_R1 at the beginning of the first TDSO frame and at the endof the last TDSO frame during the test. Similarly, both R_(b) and T_(b)can be derived from the values of the base station counters. Forexample, R_(b) can be calculated as the difference of the values of thecorresponding counter in the base station at the beginning of the firstTDSO frame and at the end of the last TDSO frame during the test.

[0781] No text.

[0782] Calculating p and q Based on D and B

[0783] Given the transition probabilities p and q, the average frameactivity (D) and the average burst length (B) can be calculated based onthe following equations:

[0784] D=q/(p+q)  (Equation 1)

[0785] B=1/p  (Equation 2)

[0786] However, to inversely calculate p and q based on the desired Dand B, cautions have to be taken since D and B are dependent on eachother and some combinations cannot be achieved as explained below:

[0787] From Equation 1 and Equation 2,

[0788] D=Bq/(1+Bq)  (Equation 3)

[0789] B=D/((1−-D)q)  (Equation 4)

[0790] Equation 3 shows that given a fixed B, D varies from 0 toB/(1+B), when q varies from 0 to 1. Similarly, Equation 4 shows thatgiven a fixed value of D, B varies from D/(1−D) to infinity.

[0791] For example, if B is set to 2, D has to be smaller than ⅔. As aresult, the frame activity (D) can never get higher than ⅔ when B is setto 2. Similarly, if D is set to {fraction (7/10)}, B has to be greaterthan {fraction (7/3)}.

[0792] The corresponding valid values of p and q can be calculated fromEquation 1 and Equation 2 given a valid pair of D and B.

[0793] The foregoing description of the preferred embodiments isprovided to enable any person skilled in the art to make or use thepresent invention. Various modifications to these embodiments will bereadily apparent to those skilled in the art, and the generic principlesdefined herein may be applied to other embodiments without the use ofthe inventive faculty. Thus, the present invention is not intended to belimited to the embodiments shown herein but is to be accorded the widestscope consistent with the principles and novel features disclosedherein.

WHAT IS CLAIMED IS:
 1. A method for generating test data for testing aparticular channel in a wireless communication system, comprising:generating a sequence of data bits based on a pseudo-random numbergenerator; and forming a plurality of data blocks for transmission overa plurality of time intervals on the particular channel, wherein eachdata block includes at least a portion of the generated sequence of databits.
 2. The method of claim 1, wherein each time interval correspondsto a frame on the particular traffic channel, and wherein the sequenceof data bits includes at least N times a maximum number of bits expectedto be transmitted for one fame on the particular channel, where N is twoor greater.
 3. The method of claim 1, further comprising: storing thegenerated sequence of data bits to a buffer.
 4. The method of claim 3,wherein the buffer is operated as a circular buffer, the method furthercomprising: retrieving data bits for each data block from a particularsection of the circular buffer.
 5. The method of claim 4, wherein astarting location in the circular buffer from which to retrieve databits for a particular data block is determined based in part on a valueobtained from the pseudo-random number generator.
 6. The method of claim5, further comprising: formatting the value obtained from thepseudo-random number generator; and advancing a pointer for the circularbuffer by a number of positions determined based on the formattednumber.
 7. The method of claim 6, wherein a 31-bit value is obtainedfrom the pseudo-random number generator, and wherein the formattingincludes generating a 24-bit number with 24 most significant bits of the31-bit value, and generating the formatted number with six leastsignificant bits of the 24-bit number.
 8. The method of claim 1, whereinthe generating the sequence of data bits includes obtaining a valuecorresponding to a current state of the pseudo-random number generator,forming a set of data bits based on the obtained value, and updating thepseudo-random number generator.
 9. The method of claim 8, wherein thegenerating the sequence of data bits further includes repeating theobtaining, forming, and updating a plurality of times, and concatenatinga plurality of sets of data bits formed based on a plurality of valuesobtained from the pseudo-random number generator to generate thesequence of data bits.
 10. The method of claim 8, wherein the formingincludes extracting a most significant portion of the obtained value,and rearranging bytes in the extracted most significant portion to formthe set of data bits.
 11. The method of claim 10, wherein a 31-bit valueis obtained from the pseudo-random number generator, a 24-bit value isextracted from the most significant portion of the obtained value, andthe bytes of the 24-bit value are rearranged in little-endian order. 12.The method of claim 1, further comprising: reinitializing thepseudo-random number generator at each synchronization timecorresponding to a start of a new test interval.
 13. The method of claim12, wherein each test interval has a duration of 10.24 seconds.
 14. Themethod of claim 12, wherein the synchronization time is determined basedin part on a system frame number for a frame on the particular trafficchannel.
 15. The method of claim 14, wherein the synchronization time isfurther determined based on a public long code mask (PLCM) assigned to aremote terminal designated to receive the data blocks.
 16. The method ofclaim 1, wherein a plurality of channels are concurrently tested, andwherein a plurality of pseudo-random number generators are used togenerate test data for testing the plurality of channels.
 17. The methodof claim 16, wherein one pseudo-random number generator is used togenerate test data for each channel.
 18. The method of claim 17, whereinthe test data generated for each channel is stored to a respectivebuffer.
 19. A method for generating test data for testing a particularchannel in a wireless communication system, comprising: selecting aparticular one of a plurality of available test data types; generating asequence of data bits of the selected test data type; and forming aplurality of data blocks for transmission over a plurality of timeintervals on the particular channel, wherein each data block includes atleast a portion of the generated sequence of data bits.
 20. The methodof claim 19, wherein the available test data types include test datagenerated based on a defined data pattern and test data pseudo-randomlygenerated.
 21. The method of claim 20, wherein the sequence of data bitsgenerated based on the defined data pattern includes a plurality ofbytes of a particular value.
 22. The method of claim 21, wherein thedefined data pattern is a sequence of a particular number of ones.
 23. Amethod for testing a particular channel in a wireless communicationsystem, comprising: determining a transmission state of a current framefor the particular channel, wherein transmission on the particularchannel occurs over frames, and wherein each frame corresponds to aparticular time interval; generating one or more blocks of test data forthe current frame if the determined transmission state indicates thattest data is to be transmitted; and transmitting the one or moregenerated blocks of test data on the particular channel.
 24. The methodof claim 23, further comprising: maintaining a two-state Markov chain torepresent the transmission state for the particular channel.
 25. Themethod of claim 24, wherein the two-state Markov chain includes an ONstate signifying transmission of test data on the particular channel andan OFF state signifying no transmission of test data on the particularchannel.
 26. The method of claim 25, further comprising: maintaining apseudo-random number generator to determine transitions between the ONand OFF states of the Markov chain.
 27. The method of claim 26, furthercomprising: initializing the pseudo-random number generator prior tostart of testing the particular channel.
 28. The method of claim 26,further comprising: obtaining a value based on a current state of thepseudo-random number generator; and transitioning from the ON state tothe OFF state if a current state of the Markov chain is the ON state andthe obtained value is below a first threshold value.
 29. The method ofclaim 28, further comprising: transitioning from the OFF state to the ONstate if the current state of the Markov chain is the OFF state and theobtained value is below a second threshold value.
 30. The method ofclaim 29, wherein the first and second thresholds values areconfigurable test parameters.
 31. The method of claim 25, whereintransition between the ON state and the OFF state is based on a firstprobability and transition between the OFF state and the ON state isbased on a second probability.
 32. The method of claim 31, wherein thefirst and second probabilities are selected to achieve a particularaverage frame activity on the particular channel indicative of anaverage duty cycle for transmissions on the channel.
 33. The method ofclaim 32, wherein the average frame activity is a selectable testparameter.
 34. The method of claim 31, wherein the first and secondprobabilities are selected to achieve a particular average burst lengthon the particular channel indicative of an average duration fortransmissions on the channel.
 35. The method of claim 23, whereintransmission of test data occurs on the particular channel for aparticular ON duration followed by no transmission of test data for aparticular OFF duration.
 36. The method of claim 35, wherein the ON andOFF durations are configurable test parameters.
 37. The method of claim26, wherein a plurality of channels are concurrently tested, and whereina two-state Markov chain is maintained for each channel being tested.38. The method of claim 37, wherein one pseudo-random number generatoris maintained to determine transitions between Markov states for eachset of one or more channels having a frame interval that is differentfrom frame intervals of other channels being tested.
 39. The method ofclaim 37, wherein a first pseudo-random number generator is maintainedto determine transitions between Markov states for a first set of one ormore channels having a first frame interval, and wherein a secondpseudo-random number generator is maintained to determine transitionsbetween Markov states for a second set of one or more channels having asecond frame interval.
 40. The method of claim 39, wherein the firstframe interval is 20 msec and the second frame interval is 40 msec or 80msec.
 41. A method for testing a plurality of channels in a wirelesscommunication system, comprising: defining values for a set of testparameters for each of the plurality of channels to be tested; andtesting each of the plurality of channels in accordance with respectivevalues defined for the set of test parameters.
 42. The method of claim41, wherein the plurality of channels have two or more different framelengths.
 43. The method of claim 41, wherein the plurality of channelshave frame lengths selected from the group consisting of 5 msec, 20msec, 40 msec, and 80 msec.
 44. The method of claim 41, wherein theplurality of channels include at least one forward traffic channel andat least one reverse traffic channel.
 45. The method of claim 41,further comprising: generating data blocks for transmission over aplurality of frames on the plurality of channels, wherein each datablock includes a header that identifies the particular channel on whichthe data block is transmitted.
 46. The method of claim 41, wherein eachtraffic channel to be tested is associate with a respective sequence oftest data bits.
 47. The method of claim 41, wherein each traffic channelto be tested is associate with a respective average frame activity. 48.The method of claim 41, wherein each traffic channel to be tested isassociate with a respective average burst length.
 49. The method ofclaim 41, further comprising: maintaining a two-state Markov chain torepresent a transmission state for each of the plurality of channels,wherein the two-state Markov chain for each channel includes an ON statesignifying transmission of test data on the channel and an OFF statesignifying no transmission of test data on the channel.
 50. The methodof claim 49, further comprising: maintaining one or more pseudo-randomnumber generators to determine transitions between the ON and OFF statesof Markov chains for the plurality of channels.
 51. The method of claim50, wherein one pseudo-random number generator is maintained for eachset of one or more channels having same frame length.
 52. The method ofclaim 51, wherein a first pseudo-random number generator is maintainedfor one or more channels having frame length of 20 msec and a secondpseudo-random number generator is maintained for one or more channelshaving frame length of 40 msec or 80 msec.
 53. A method for testing aparticular channel in a wireless communication system, comprising:sending from a first entity to a second entity a first message havingincluded therein one or more proposed values for one or more parametersfor testing the particular channel; and receiving from the second entitya response message rejecting or accepting the one or more proposedvalues sent in the first message.
 54. The method of claim 53, whereinthe response message includes one or more alternative values for one ormore parameters rejected by the second entity.
 55. The method of claim53, further comprising: sending to the second entity a second messagehaving included therein one or more values for one or more parametersrejected by the second entity.
 56. The method of claim 53, wherein thefirst entity is a remote terminal and the second entity is a basestation in the communication system.
 57. A transmitting entity in awireless communication system, comprising: at least one pseudo-randomnumber generator, each generator configured to generate pseudo-randomnumbers used to generate a sequence of data bits; and at least onebuffer operatively coupled to the at least one generator, each bufferconfigured to store a respective generated sequence of data bits, andwherein a plurality of data blocks are formed for transmission over aplurality of time intervals on a particular channel, and wherein eachdata block includes at least a portion of a particular sequence of databits from a particular buffer.
 58. The transmitting entity claim 57,further comprising: a controller configured to select one of a pluralityof available test data types, wherein the available test data typesinclude test data generated based on a defined data pattern and testdata pseudo-randomly generated.
 59. The transmitting entity claim 58,wherein the controller is further configured to determine a transmissionstate of a current frame for the particular channel, and wherein thetransmission state is either an ON state signifying transmission of testdata on the particular channel in the current frame or an OFF statesignifying no transmission of test data on the particular channel in thecurrent frame.
 60. The transmitting entity claim 57, wherein a pluralityof channels are concurrently tested, and wherein one pseudo-randomnumber generator and one buffer are associate with each channel to betested.
 61. In a wireless communication system in which a plurality offrames are transmitted, a method for attaining a long-term average valueon a duty cycle using a two-state Markov chain, the method comprising:driving on/off transitions of a test data service option (TDSO) processwith a first pseudo-random number generator during a frame period if theframe period is a first length in time; and driving the on/offtransitions with a second pseudo-random number generator during theframe period if the frame period is either a second length in time or athird length in time.
 62. The method of claim 61, wherein the first andsecond pseudo-random number generators provide 24-bits pseudo-randomnumbers.
 63. The method of claim 61, wherein the first length in time is20 msec.
 64. The method of claim 61, wherein the second length in timeis 40 msec and the third length in time is 80 msec.
 65. The method ofclaim 61, wherein if the frame period is equal to either the secondlength in time or the third length in time, the frame is a supplementalchannel.
 66. The method of claim 61, wherein the long-term average valueis configurable.
 67. A method of exchanging test parameter valuesbetween a remote terminal and a base station in a wireless communicationsystem, the method comprising: sending proposed test parameter valuesfrom the remote terminal to the base station; and receiving a serviceoption control message from the base station rejecting or negativelyacknowledging the proposed test parameter values.
 68. A method ofconstructing a circular buffer storing a plurality of maximum-rateframes transmitted on a particular channel in a wireless communicationsystem, the method comprising: constructing data for the circular bufferfrom iterations of a pseudo-random number generator a plurality of timesfor each test interval; and using a set of bits from a number generatedby the pseudo-random number generator to indicate a byte offset todetermine a starting position in the circular buffer from which to buildone or more data blocks for a particular frame period.
 69. The method ofclaim 68, wherein the pseudo-random number generator is a 31-bitpseudo-random number generator.
 70. The method of claim 68, wherein theset of bits is obtained by extracting 24 most significant bits of numbergenerated by the pseudo-random number generator, and extracting sixleast significant bits of the 24 most significant bits.
 71. The methodof claim 68, wherein the test interval is defined to coincide with asynchronization frame of the channel.
 72. The method of claim 71,wherein the test interval has a duration of 10.24 seconds.